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

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

Альтернативно (и более того), как подсказывают некоторые комментарии, покупайте больше оперативной памяти.

Для ответа на вопрос заголовка используйте oom_score_adj(ядро >=2.6.36) или для более ранних ядер (>=2.6.11) oom_adj, см. man 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, и разобраться с этим.

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

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

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

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

• Проверьте, что все (аппаратное обеспечение, или имитируемое vm's и т.д.) 64-битное. (см., например: https://askubuntu.com/questions/313379/i-installed-a-64-bit-os-in-a-32-bit-processor/313381 ). Подсистема cpu & host OS & vm OS & vm OS должна быть полностью 64-битной, иначе у вас не будет реальной 64-битной vm

• Хорошо бы прочитать:

  • Как диагностировать причины процессов убивания оом-убийц : именно на этом сайте. Даёт хорошую ссылку, http://linux-mm.org/OOM_Killer, а другой пользователь представляет инструмент atop, который может помочь в диагностике происходящего
  • 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 : дает возможность проверить, как ваша система выделяет память
  • https://serverfault.com/a/724518/146493 : отличный ответ, дающий отличный способ узнать, что же на самом деле произошло (но... был задан 32-битный вопрос, так что ymmv. Тем не менее, невероятное чтение и ответ).

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

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

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

Частично это одна из строк, описывающая, почему это происходит:

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

|The Первая строка - это маска 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) имеет тенденцию отображать память для зон вне стандартных диапазонов 896MiB, непосредственно доступных на 32-битных системах. На x86_64 HighMem/Normal, кажется, охватывает все страницы размером выше 3Гб.

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

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

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

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

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

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

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

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

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

В терминах разрешения этого вопроса у вас есть два варианта.

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

2. Request that linode set the 'available memory' on the system to be same 1GiB assignment as the 'current memory'. Таким образом, система никогда не будет вздуваться и никогда не получит Нормальную зону при загрузке, сохраняя флаг ясным. Удачи им в этом!

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

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

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

Краткая история - попробуйте другая версия ядра. У меня есть система, которая показывала ошибки 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 ГБ. Конечно, для некоторых типов программного обеспечения требуется куча ОЗУ, но в моем случае (поскольку я использую одно и то же программное обеспечение только на другом ядре) это явно не так.

Я столкнулся с этим на виртуальной машине без подкачки 2G ram, работающей под управлением Debian Stretch (последней)

только при запуске скрипта из пользовательского cron. Тот же скрипт работал из командной строки!!

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