Как заставить Linux OOM killer не убивать мой процесс?

Это проблема в сочетании двух факторов:

• С помощью виртуальной машины.
• Возможная ошибка ядра.

Отчасти это одна из строк, объясняющих, почему это происходит:

Mar  7 02:43:11 myhost kernel: memcheck-amd64- invoked oom-killer: gfp_mask=0x24002c2, order=0, oom_score_adj=0

Другая строка такова:

Mar  7 02:43:11 myhost kernel: 0 pages HighMem/MovableOnly

| Первая строка - это маска GFP, назначенная для выделения. Он в основном описывает, что ядру разрешено / не разрешено делать для удовлетворения этого запроса. Маска обозначает набор стандартных флагов. Однако последний бит, «2», указывает, что выделение памяти должно происходить из HighMem зона.

Если вы внимательно посмотрите на вывод OOM, вы не увидите HighMem/Normal зона действительно существует.

Mar  7 02:43:11 myhost kernel: Node 0 DMA: 20*4kB (UM) 17*8kB (UM) 13*16kB (M) 14*32kB (UM) 8*64kB (UM) 4*128kB (M) 4*256kB (M) 0*512kB 1*1024kB (M) 0*2048kB 0*4096kB = 3944kB
Mar  7 02:43:11 myhost kernel: Node 0 DMA32: 934*4kB (UM) 28*8kB (UM) 0*16kB 0*32kB 0*64kB 0*128kB 0*256kB 0*512kB 0*1024kB 0*2048kB 0*4096kB = 3960kB

HighMem (обычно также называется Normal на x86_64) имеет тенденцию отображать память для зон за пределами стандартного диапазона 896 МБ, напрямую доступного ядру в 32-разрядных системах. На x86_64 HighMem/Normal похоже, покрывает все страницы размером более 3 ГБ.

DMA32 содержит зону, используемую для памяти, которая будет доступна на 32-битных устройствах DMA, то есть вы можете адресовать их с помощью 4-х байтовых указателей. Я считаю DMA для 16-битных устройств DMA.

Вообще говоря, в системах с низким объемом памяти Normal не было бы, учитывая, что DMA32 уже охватывает все доступные виртуальные адреса.

Причина, по которой вы убиваете OOM, заключается в том, что есть выделение памяти для HighMem зона с 0 доступными страницами. Учитывая, что обработчик нехватки памяти не имеет абсолютно никакого способа удовлетворить потребности этой зоны в страницах для использования путем подкачки, уничтожения других процессов или любого другого трюка, OOM-killer просто убивает его.

Я считаю, что это вызвано раздутием виртуальной машины хоста при загрузке. В системах KVM вы можете установить два значения.

• Текущая память.
• Доступная память.

Это работает так: вы можете добавить на сервер оперативную память до объема доступной памяти. Однако вашей системе фактически предоставляется текущая память.

Когда виртуальная машина KVM загружается, она запускается с максимально возможным выделением памяти (доступная память). Постепенно во время фазы загрузки системы KVM захватывает эту память, используя ее раздувание, оставляя вам вместо этого текущие настройки памяти, которые у вас есть.

Я считаю, что здесь произошло именно это. Linode позволяет расширить память, давая вам гораздо больше при запуске системы.

Это означает, что есть Normal/HighMem зона в начале срока службы системы. Когда гипервизор закрывает его, нормальная зона по праву исчезает из диспетчера памяти. Но я подозреваю, что установка флага того, доступна ли указанная зона для выделения из не очищается, когда должно. Это приводит к тому, что ядро ​​пытается выделить из несуществующей зоны.

Что касается решения этой проблемы, у вас есть два варианта.

1. Включите это в списки рассылки ядра, чтобы узнать, действительно ли это ошибка, ожидаемое поведение или вообще ничего общего с тем, что я говорю.

2. Попросите, чтобы линод установил для «доступной памяти» в системе то же значение 1 ГБ, что и для «текущей памяти». Таким образом, система никогда не срабатывает и никогда не попадает в нормальную зону при загрузке, не снимая флажка. Удачи им в этом!

Вы должны иметь возможность проверить, что это так, настроив свою собственную виртуальную машину в параметрах KVM, доступных для 6 ГБ, текущих до 1 ГБ и запустив свой тест с тем же ядром, чтобы увидеть, происходит ли такое поведение, которое вы видите выше. Если это так, измените параметр «Доступен», чтобы он равнялся току 1 ГБ, и повторите тест.

Я делаю здесь несколько обоснованных предположений и читаю немного между строк, чтобы прийти к такому ответу, но то, что я говорю, похоже, соответствует уже изложенным фактам.

Я предлагаю проверить свою гипотезу и сообщить нам результат.

Чтобы ответить на ваш вопрос заголовка, используйте oom_score_adj(ядро> = 2.6.36) или для более ранних ядер (> = 2.6.11) oom_adj, увидишь человека proc

/ proc / [pid] / oom_score_adj (начиная с Linux 2.6.36) Этот файл можно использовать для настройки эвристики проверки достоверности информации, используемой для выбора процесса, который будет завершен в условиях нехватки памяти ...

/ proc / [pid] / oom_adj (начиная с Linux 2.6.11) Этот файл можно использовать для настройки оценки, используемой для выбора того, какой процесс должен быть остановлен в ситуации нехватки памяти (OOM) ...

Можно еще многое прочитать, но установка oom_score_adj на -1000 или oom_adj на -17 позволит достичь того, чего вы хотите.

Беда в другом убьют. Возможно, было бы лучше определить, почему вызывается OOM, и разобраться с этим.

Несколько мыслей (из моих комментариев выше) и ссылки на интересные статьи о вашей ситуации:

• Я рекомендую вам проверить, 1) что вы можете адресовать более 3Гб с вашим текущим ядром и конфигурацией (& cpu) [потому что, если 3Гб является пределом для вашей системы и ОС, вы его превышаете]. 2) что вы разрешаете подкачку, и подсистема подкачки находится на своем месте и работает. удачи (объяснять не буду, это зависит от ваших настроек и особенностей. Поисковые системы помогут). И что вы не переполняете таблицу ядра (nb pid? Или что-то еще (некоторые могут быть установлены во время компиляции ядра).

• Убедитесь, что все это (оборудование или виртуальное оборудование, смоделированное и т. Д.) Является 64-битным. (см. например: https://askubuntu.com/questions/313379/i-installed-a-64-bit-os-in-a-32-bit-processor/313381 ). ЦП и ОС хоста, подсистема виртуальной машины и операционная система виртуальной машины должны быть 64-разрядными, иначе у вас не будет настоящей 64-разрядной виртуальной машины.

• Несколько хороших чтений:

  • Как диагностировать причины процессов убийства oom-killer : на этом самом сайте. Дает красивую ссылку, http://linux-mm.org/OOM_Killer, а другой пользователь представляет инструмент поверх, который может помочь диагностировать, что происходит
  • https://www.kernel.org/doc/gorman/html/understand/understand016.html : 3.12 показывает дерево решений для OOM (более старой версии, так что ymmv. Прочтите источник ^^)
  • https://lwn.net/Articles/317814/ : «Укрощение убийцы OOM» показывает, среди прочего, как создать «невидимую» группу и поместить в нее свой процесс.
  • http://eloquence.marxmeier.com/sdb/html/linux_limits.html : показывает некоторые общие ограничения ядра
  • http://win.tue.nl/~aeb/linux/lk/lk-9.html : хорошее чтение (потраченное впустую пространство некоторыми методами распределения и т. д.), хотя оно действительно устарело (и, таким образом, относится только к 32-битным архитектурам ...)
  • http://bl0rg.krunch.be/oom-frag.html показывает некоторые причины, по которым «Убийца OOM может быть вызван, даже если есть еще много доступной памяти»
  • https://stackoverflow.com/questions/17935873/malloc-fails-when-there-is-still-plenty-of-swap-left : дает возможность проверить, как ваша система распределяет память
  • https://serverfault.com/a/724518/146493 : отличный ответ, дающий подробный способ узнать, что на самом деле произошло (но ... нацелился на 32-битный вопрос, так что ymmv. Тем не менее, все еще невероятное чтение и ответ).

• и наконец : http://www.oracle.com/technetwork/articles/servers-storage-dev/oom-killer-1911807.html показывает способ предотвратить ваш процесс от убийцы oom! ( echo -17 > /proc/PROCESSPID/oom_adj ). Может быть подвержен изменениям и может быть плохим (вызвать другие виды сбоев, поскольку теперь система не может просто убить главного нарушителя ...). Используйте с осторожностью. @iain обратите внимание, что «oom_adj» предназначен для старых ядер, и его следует заменить на «oom_score_adj» в более новых. Спасибо, Иэн)

помимо упомянутого oom_score_adj увеличение для рассматриваемого процесса (что, вероятно, не сильно поможет - это снизит вероятность того, что этот процесс будет убит ПЕРВЫМ, но поскольку это только процессная система, интенсивно использующая память, вероятно, не восстановится, пока не будет окончательно убита) , вот несколько идей для настройки:

• если вы установите vm.overcommit_memory=2, также настроить vm.overcommit_ratio возможно до 90 (или установите vm.overcommit_memory=0 - видеть ядро overcommit docs)
• увеличение vm.min_free_kbytes для того, чтобы всегда оставлять физическую оперативную память свободной и, таким образом, снизить вероятность того, что OOM нужно что-то убить (но не переусердствуйте, так как он будет OOM мгновенно).
• увеличение vm.swappiness до 100 (сделать замена ядра более удобна)

Обратите внимание: если у вас слишком мало памяти для выполнения поставленной задачи, даже если вы не используете OOM, он может (а может и не) стать ЧРЕЗВЫЧАЙНО медленным - получасовая работа (в системе с достаточным объемом ОЗУ) может легко занять несколько недель (когда ОЗУ заменяется подкачкой) в крайних случаях, или даже зависание всей виртуальной машины. Это особенно актуально, если своп выполняется на классических вращающихся дисках (в отличие от SSD) из-за массивных случайных операций чтения / записи, которые для них очень дороги.

Я бы попытался включить чрезмерную нагрузку и посмотреть, поможет ли это. Кажется, что ваш процесс не работает внутри fork вызов, который требует столько же виртуальной памяти, сколько было у исходного процесса. overcommit_memory=2 не делает ваш процесс невосприимчивым к OOM killer, он просто предотвращает его запуск из-за выделения слишком большого количества ресурсов. Другие процессы могут вызывать несвязанные ошибки распределения (например, получение непрерывного блока памяти), которые по-прежнему запускают убийцу OOM и удаляют ваш процесс.

В качестве альтернативы (и ближе к делу), как предлагается в нескольких комментариях, купите больше оперативной памяти.

Краткая история - попробуйте другую версию ядра. У меня есть система, которая показывала ошибки OOM с ядрами 4.2.0-x и 4.4.0-x, но не с 3.19.0-x.

Длинная история: (не слишком долго!) У меня все еще в эксплуатации Compaq DC5000 - в настоящее время с 512 МБ ОЗУ (и некоторая часть этого, например, 32-128 МБ, отведена на бортовое видео ..) В основном обслуживает NFS, у меня есть монитор, подключенный к нему, поэтому иногда я вхожу в него (Ubuntu Classic, без Unity).

Через Ubuntu HWE я долгое время работал с ядром 3.19.x; это закончилось бы заменой примерно 200-300 МБ материала, но, очевидно, это был неиспользованный материал, из-за того, что ему пришлось бы заменять его позже, насколько я мог судить, не было бы никакой активности подкачки.

Ядро 4.2.0-x, а теперь ядро ​​4.4.0-x, я могу запустить короткую запись NFS в него, только 220 МБ в подкачку (т.е. 1,3 ГБ свободно), и он начнет убивать OOM. Я не буду утверждать, что это ошибка ядра или "проблема настройки" (например, резерв в 64 МБ, который обычно хорошо, но слишком велик для системы ~ 400 МБ или около того?)

Никакого неуважения к тем, кто говорит, что это как-то ломается только потому, что он рассчитывает использовать своп; при всем уважении вы ошибаетесь. Это будет не быстро, но я использовал 1 или 2 ГБ в своп на нескольких системах 512 МБ - 1 ГБ. Конечно, для некоторых типов программного обеспечения требуется куча ОЗУ, но в моем случае (поскольку я запускаю одно и то же программное обеспечение только на другом ядре) это явно не так.