Ubuntu может убить процесс из-за нехватки памяти и как это узнать

Это не Ubuntu, который делает это. Это - ядро Linux, которое делает это. Википедия имеет тему на этом:

Из памяти (OOM) является часто нежелательным состоянием компьютерной эксплуатации, где никакая дополнительная память не может быть выделена для использования программами или операционной системой. Такая система будет неспособна загрузить любые дополнительные программы, и так как много программ могут загрузить дополнительные данные в память во время выполнения, они прекратят функционировать правильно. Это происходит, потому что вся доступная память, включая дисковую область подкачки, была выделена.

В целом должно быть уведомление в любом/var/log/syslog (debian базирующиеся системы) или /var/log/messages. grep "Killed process" /var/log/syslog должен показать, уничтожила ли система процесс.

Интересные темы: , "Как обнаружить то, что уничтожает процесс?" на стеке и этой статье о lwn.net .

страница проекта для OOM имеет много подсказок:

, Что вызывает эти события OOM?

• ядро действительно вне памяти. Рабочая нагрузка использовала больше памяти, чем система имеет RAM и область подкачки. Что такое SwapFree и MemFree в/proc/meminfo? Если оба являются очень низкими (меньше чем 1% их общего количества), то рабочая нагрузка может быть виновным. (если mlock () или HugeTLB не включены, посмотрите ниже...)

• , ядро вне низкой памяти на 32-разрядной архитектуре. Что такое LowFree в/proc/meminfo? Если это очень низко, но HighFree намного выше, то у Вас есть это условие. Эта рабочая нагрузка может извлечь выгоду из того, чтобы быть выполненным на 64-разрядной платформе или ядре.

• существует структура данных ядра или утечка памяти. Что такое SwapFree и MemFree в/proc/meminfo? Каково количество объектов task_struct в slabinfo? Система разветвляла столько процессов, что она исчерпала память? Какие объекты в/proc/slabinfo поднимают большую часть пространства? Если один вид объекта поднимает обширную часть общей памяти системы, тот объект может быть ответственным. Согласуйте с экспертами по подсистеме для области, из которой прибывает тот объект. Для наблюдения объектного использования выполните это на командной строке:

  awk '{printf "%5d MB %s\n", $3*$4/(1024*1024), $1}' < /proc/slabinfo | sort -n
  

• ядро не использует свою область подкачки правильно. Если приложение использует mlock страницы () или HugeTLBfs, оно не может быть в состоянии использовать свою область подкачки для того приложения. Если это происходит, SwapFree может все еще иметь очень большое значение, когда OOM происходит. Эти две функции не позволяют системе выгружать затронутую память, однако, так злоупотребление их может память выхлопной системы и оставлять систему без другого обращения за помощью. Для системы также возможно оказаться в своего рода мертвой блокировке. Выписывание данных к диску может, самому, потребуйте памяти выделения для различных структур данных ввода-вывода. Если система не может найти даже, что память, самые функции, используемые для создания свободной памяти, будет зажата в тиски, и система, вероятно, исчерпает память. Возможно сделать некоторую незначительную настройку для запуска подкачки страниц ранее, но если система не может выписать грязные страницы достаточно быстро к свободной памяти, можно только прийти к заключению, что рабочая нагрузка неправильный измерена для установленной памяти и существует мало, чтобы быть сделанным. Повышение значения в/proc/sys/vm/min_free_kbytes заставит систему начинать исправлять память в более раннее время, чем это имело бы прежде. Это делает его тяжелее для вхождения в эти виды мертвых блокировок. Если Вы получаете эти мертвые блокировки, это - хорошее значение для настройки. При столкновении со случаем, где настройка этого значения помогает, сообщите о нем. Мы, возможно, должны внести изменения в значения по умолчанию.

• ядро приняло плохое решение и неправильно читало его статистику. Это пошло OOM, в то время как это все еще имело много хорошей RAM для использования.

• Что-то действительно патологическое происходит, ядро на самом деле решает пойти OOM после того, как это имеет, тратят "значительную" память сканирования количества времени для чего-то к свободному. С 2.6.19, происходит это "существенное количество" после того, как VM просканировал сумму, равную всему из (в настоящее время) active+inactive страницы в зоне шесть раз. Если ядро быстро сканирует страницы, но Ваши устройства ввода-вывода (подкачка, файловая система, или сетевая фс) являются слишком медленными, ядро может судить, что нет никаких сделанных успехов, и инициируйте OOM, даже если существует бесплатная подкачка.

Выполнение этот сценарий во время Вашего теста и OOM. Выполните сценарий, отправьте вывод эксперту VM. Сделайте, чтобы они проанализировали его. Тогда возвратитесь и обновите эту страницу.;)