Out of memory ошибка linux
Обновлено: 08.07.2024
Я уверен, что каждый пользователь в своей жизни хоть раз сталкивался с явлением переполнения оперативной памяти или OOM (Out Of Memory). Все помнят как это происходит: система встаёт раком колом, ядро начинает грузить свопом жёсткий диск на 100%, хорошо если можно хоть курсором двигать, хотя это уже делу не поможет. В этом случае помогает только перезагрузка. А ведь мы же только Libre Office с Chromium на 2 ГБ ОЗУ запустили! Не понятно, почему ядро Linux так плохо справляется с переполнением оперативки, но с этим явлением можно успешно бороться своими силами и при минимуме накладных затрат.
В борьбе с явлением OOM нам поможет Nohang — демон для GNU/Linux, предотвращающий наступление явления переполнения оперативной памяти устройства путём принудительного завершения «прожорливого» процесса.
Принцип работы
Nohang в виде демона постоянно находится в оперативной памяти устройства (потребляет
10 Мб ОЗУ) и следит за свободным количеством оперативной памяти и своп-раздела. Как только наступает условие явной нехватки ОЗУ и свопа (эти параметры указываются в конфигурационном файле приложения) Nohang принудительно завершает «жирное» приложение, вызвавшее нехватку оперативной памяти устройства.
В качестве примера — скриншот окна монитора ресурсов KDE, на котором отображена работа демона Nohang.
На среднем графике видны факты наступления состояния OOM (переполнения памяти) ОЗУ компьютера, на котором производился эксперимент. Оперативная память накачивалась бесполезными пустыми данными с помощью команды:
Осторожно! Выполнение данной команды может привести (и без установленных утилит вроде Nohang — 100% приведёт) к переполнению оперативной памяти устройства и его зависанию, сколько бы ОЗУ в нём не было установлено!
Как видно, после первой попытки своп заполнился на 100% (в качестве свопа использовался раздел zRam) так же, как и ОЗУ, после чего Nohang прибивает процесс tail и оперативная память снова освобождается, возвращаясь к значению свободного места, которое имела до начала эксперимента. Интересно то, что своп остаётся заполненным практически на 100%, но при следующих попытках исчерпать всю доступную ОЗУ это не приводит к зависанию всей системы, и Nohang снова завершает прожорливый процесс tail, освобождаю ОЗУ. По субъективным ощущениям для пользователя, происходит кратковременное подтормаживание системы на пару секунд, после чего контроль над системой возвращается без каких-либо проблем. В общем — сказка!
Установка Nohang в различных дистрибутивах Linux
Так как не все, как я, используют в своей работе Arch Linux, рассмотрим процесс установки Nohang для всех самых популярных дистрибутивов.
Arch Linux, Manjaro Linux
Debian GNU/Linux, Ubuntu, Linux Mint
Устанавливаем из Github:
Если уведомления на рабочем столе не нужны, заменяем «sudo make install-desktop» на «sudo make install»
Fedora, RHEL, openSUSE
Настройка
Все параметры Nohang настраиваются в конфигурационном файле
В принципе, всё можно оставить как есть, параметры по-умолчанию там оптимальны для любой конфигурации железа.
Включение оповещений на рабочем столе
Чтобы включить всплывающие оповещения о нехватке ОЗУ и завершении приложений Nohang, нужно в файле конфигурации изменить следующие параметры на значение «True» чтобы получилось вот так:
После чего сохранить изменения в конфигурационном файле и перезапустить Nohang для применения новой конфигурации:
Проверка
Проверяем состояние демона Nohang:
Статус работы должен быть указан зелёным цветом:
Если так — Nohang запущен и работает нормально, можно приступать к экспериментам.
Сохраняем все несохранённые данные во всех приложениях, делаем резервные копии важных данных!
Это я на всякий случай 😏 Что ж, инициируем процесс накачки оперативной памяти пустыми данными:
И смотрим что из этого получится 😀 По идее, вы можете почувтвовать непродолжительный дискомфорт, проявляющийся в зависании системы на несколько секунд, после чего Nohang должен отработать по tail и управление системы вернётся в ваши руки. А точнее, скорее всего так и произойдёт, что можно будет считать успешным достижением поставленной цели.
Как я могу получить больше информации о том, почему PID 9163 убит, и я не уверен, хранит ли linux историю для прекращенных PID где-нибудь.
Ядро будет регистрировать кучу вещей до того, как это произошло, но большинство из них, вероятно, не будут включены, в /var/log/messages зависимости от того, как (r)syslogd сконфигурирован ваш . Пытаться:
Первый должен появляться несколько раз, а второй только в одном или двух местах. Это файл, который вы хотите посмотреть.
Найдите оригинальную строку «Out of memory» в одном из файлов, который также содержит total_vm . От тридцати секунд до минуты (может быть больше, может быть меньше) перед этой строкой вы найдете что-то вроде:
Вы также должны найти таблицу где-то между этой строкой и строкой «Недостаточно памяти» с такими заголовками:
Это может не сказать вам намного больше, чем вы уже знаете, но поля:
- pid Идентификатор процесса.
- UID ID пользователя.
- tgid ID группы потоков.
- total_vm Использование виртуальной памяти (на страницах 4 КБ)
- Использование резидентной памяти rss (на страницах 4 КБ)
- nr_ptes Записи таблицы страниц
- swapents Обмен записями
- oom_score_adj Обычно 0; меньшее число указывает на то, что процесс будет менее вероятен, когда будет вызван убийца OOM.
Вы можете в основном игнорировать, nr_ptes и swapents хотя я считаю, что это факторы, определяющие, кого убивают. Это не обязательно процесс, использующий большую часть памяти, но, скорее всего, так и есть. Подробнее о процессе выбора смотрите здесь . По сути, процесс, который заканчивается наивысшим значением oom, убивается - это «счет», указанный в строке «Недостаточно памяти»; к сожалению, другие оценки не сообщаются, но эта таблица дает некоторые подсказки с точки зрения факторов.
Опять же, это, вероятно, не принесет большего, чем просто освещение очевидного: системе не хватило памяти, и ее mysqld выбрали умереть, потому что ее убийство высвободит больше всего ресурсов . Это не обязательно означает, mysqld что делает что-то не так. Вы можете взглянуть на таблицу, чтобы увидеть, что в этот момент что-то пошло не так, но не может быть никакого явного виновника: системе может не хватить памяти просто потому, что вы неправильно оценили или неправильно сконфигурировали запущенные процессы.
Что такое OOM Killer?
Убийца OOM, включенный по умолчанию, является механизмом самозащиты, использующим ядро Linux при сильном использовании памяти.
Если ядро не может найти память для выделения, когда это необходимо, она помещает страницы пользовательских данных в очередь подкачки.
Если виртуальная память (VM) не может выделять память и не может поменять ее в используемой памяти, киллер может начать убивать текущие процессы из памяти в пользовательском пространстве. он пожертвует одним или несколькими процессами, чтобы освободить память для системы, когда все остальное не удастся.
Если у вас есть строка, как показано ниже в / var / log / messages:
это означает, что киллер OOM убил серверный процесс 2592 Oracle.
Отключение OOM-KILLER в CentOS / RHEL
В Red Hat Enterprise Linux 5 и 6 нет возможности полностью отключить OOM-KILLER. См. Следующий раздел для настройки работы OOM-KILLER в RHEL 5 и RHEL 6.
Можно определить, какие процессы будут убиты путем корректировки оценки oom_killer.
В / proc / PID / есть два инструмента с метками oom_adj и oom_score.
Действительные оценки для oom_adj находятся в диапазоне от -16 до +15.
Это значение используется для вычисления «плохого» процесса с использованием алгоритма, который также учитывает, как долго процесс был запущен, среди других факторов.
Чтобы увидеть текущий счет oom_killer, просмотрите oom_score для процесса.
oom_killer сначала уничтожит процессы с наивысшими баллами.
В этом примере настраивается oom_score процесса с помощью PID 12465, чтобы уменьшить вероятность того, что oom_killer убьет его.
Существует также специальное значение -17, которое отключает oom_killer для этого процесса.
В приведенном ниже примере oom_score возвращает значение 0, указывая, что этот процесс не будет убит.
Установка «overcommit_memory» на 2, позволяет вам быть точным в отношении избыточной памяти.
Оно указывает, что ядро никогда не будет выполнять адресное пространство, большее, чем пространство подкачки, и фракцию «overcommit_ratio» физической памяти.
Когда использование памяти попадает в этот номер, больше не должно быть никаких ассигнований.
Committed_AS в / proc / meminfo показывает текущий объем памяти в системе.
Заключение
Out of Memory (OOM) относится к вычислительному состоянию, в котором выделена вся доступная память, включая пространство подкачки.
Обычно это приведет к panic error и остановке системы.
Хотя OOM нельзя полностью отключить в CentOS / RHEL 5,6; он может быть настроен на то, чтобы определить, какие процессы будут убиты, отрегулировав счет oom_killer.
Перезагрузка системы CentOS / RHEL из-за ошибки нехватки памяти:
Решение
Перезагрузка происходит из-за:
- OOM killer и физическая память / память подкачки полностью используются.
- vm.panic_on_oom был включен.
Физическая память или память подкачки должны быть увеличены, чтобы избежать OOM, иначе использование памяти приложением должно быть уменьшено.
Использование памяти приложения может быть ограничено с помощью ulimit или cgroup.
Добавить комментарий Отменить ответ
Существует множество вариантов лучших тем для Ubuntu. Но тестирование всех тем и выбор лучшей из них отнимает много времени и сил. Да и предустановленная тема может вам не понравиться. Поэтому мы отобрали 10 лучших тем Ubuntu для вашего рабочего стола Linux. Итак, как превратить рабочий стол в красивую и элегантную среду? С помощью нескольких простых.
Краткий обзор того, как работают гипервизоры и в чем разница между двумя их типами. Прежде чем вы увидите разницу между гипервизором типа 1 и типа 2 и узнаете, какой из них лучше (если это вообще возможно), давайте сначала рассмотрим, что такое гипервизор. Что такое гипервизор? Гипервизор – это системное программное обеспечение, которое выступает в качестве.
Итак, вы установили свой сервер Linux и установили все необходимые пакеты. Теперь вы собираетесь установить другой сервер с аналогичными пакетами. Вы можете сохранить команды установки первого сервера и запустить их на второй машине. Как быть, если вы делали это в течение нескольких недель и забыли некоторые детали, но вам нужно быстро запустить другой сервер. ssh.
Команда Linux top широко используется системными администраторами Linux в режиме реального времени для проверки использования системных ресурсов, таких как процессор, дисковый ввод/вывод, средняя загрузка системы, запущенные процессы и использование памяти. Я обычно использую Oracle OSWatcher Black Box (OSWbb) для сбора различных системных данных для диагностики проблем производительности в течение определенного периода времени. Но если вы.
Читайте также: