Как заставить Linux OOM killer не убивать мои процессы, когда физическая память невелика, но есть много места подкачки?
Я отключил OOM Killing и overcommit с помощью sysctl vm.overcommit_memory = 2.
Виртуальная машина имеет 3 ГБ абсолютно бесплатного нефрагментированного свопа, а процессы, которые уничтожаются OOM, имеют максимальное использование памяти менее 200 МБ.
Я знаю, что долгосрочный обмен будет ужасен для производительности, но мне нужно использовать обмен прямо сейчас, чтобы провести функциональное тестирование в valgrind, где требования к памяти намного выше.
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: memcheck-amd64- cpuset=/ mems_allowed=0
Mar 7 02:43:11 myhost kernel: CPU: 0 PID: 3841 Comm: memcheck-amd64- Not tainted 4.4.0-x86_64-linode63 #2
Mar 7 02:43:11 myhost kernel: Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
Mar 7 02:43:11 myhost kernel: 0000000000000000 0000000000000000 ffffffff8158cbcc ffff880032d7bc18
Mar 7 02:43:11 myhost kernel: ffffffff811c6a55 00000015118e701d ffffffff81044a8d 00000000000003e2
Mar 7 02:43:11 myhost kernel: ffffffff8110f5a1 0000000000000000 00000000000003e2 ffffffff81cf15cc
Mar 7 02:43:11 myhost kernel: Call Trace:
Mar 7 02:43:11 myhost kernel: [<ffffffff8158cbcc>] ? dump_stack+0x40/0x50
Mar 7 02:43:11 myhost kernel: [<ffffffff811c6a55>] ? dump_header+0x59/0x1dd
Mar 7 02:43:11 myhost kernel: [<ffffffff81044a8d>] ? kvm_clock_read+0x1b/0x1d
Mar 7 02:43:11 myhost kernel: [<ffffffff8110f5a1>] ? __raw_callee_save___pv_queued_spin_unlock+0x11/0x1e
Mar 7 02:43:11 myhost kernel: [<ffffffff81183316>] ? oom_kill_process+0xc0/0x34f
Mar 7 02:43:11 myhost kernel: [<ffffffff811839b2>] ? out_of_memory+0x3bf/0x406
Mar 7 02:43:11 myhost kernel: [<ffffffff81187bbd>] ? __alloc_pages_nodemask+0x8ba/0x9d8
Mar 7 02:43:11 myhost kernel: [<ffffffff811b82e8>] ? alloc_pages_current+0xbc/0xe0
Mar 7 02:43:11 myhost kernel: [<ffffffff811b096c>] ? __vmalloc_node_range+0x12d/0x20a
Mar 7 02:43:11 myhost kernel: [<ffffffff811e0e62>] ? alloc_fdtable+0x6a/0xd8
Mar 7 02:43:11 myhost kernel: [<ffffffff811b0a83>] ? __vmalloc_node+0x3a/0x3f
Mar 7 02:43:11 myhost kernel: [<ffffffff811e0e62>] ? alloc_fdtable+0x6a/0xd8
Mar 7 02:43:11 myhost kernel: [<ffffffff811b0ab0>] ? vmalloc+0x28/0x2a
Mar 7 02:43:11 myhost kernel: [<ffffffff811e0e62>] ? alloc_fdtable+0x6a/0xd8
Mar 7 02:43:11 myhost kernel: [<ffffffff811e1338>] ? dup_fd+0x103/0x1f0
Mar 7 02:43:11 myhost kernel: [<ffffffff810dd143>] ? copy_process+0x5aa/0x160d
Mar 7 02:43:11 myhost kernel: [<ffffffff8110f5a1>] ? __raw_callee_save___pv_queued_spin_unlock+0x11/0x1e
Mar 7 02:43:11 myhost kernel: [<ffffffff810de2fc>] ? _do_fork+0x7d/0x291
Mar 7 02:43:11 myhost kernel: [<ffffffff810ea186>] ? __set_current_blocked+0x47/0x52
Mar 7 02:43:11 myhost kernel: [<ffffffff810ea1f2>] ? sigprocmask+0x61/0x6a
Mar 7 02:43:11 myhost kernel: [<ffffffff81998eae>] ? entry_SYSCALL_64_fastpath+0x12/0x71
Mar 7 02:43:11 myhost kernel: Mem-Info:
Mar 7 02:43:11 myhost kernel: active_anon:15 inactive_anon:18 isolated_anon:0
Mar 7 02:43:11 myhost kernel: active_file:7 inactive_file:8 isolated_file:0
Mar 7 02:43:11 myhost kernel: unevictable:0 dirty:3 writeback:26 unstable:0
Mar 7 02:43:11 myhost kernel: slab_reclaimable:1798 slab_unreclaimable:3674
Mar 7 02:43:11 myhost kernel: mapped:8 shmem:1 pagetables:752 bounce:0
Mar 7 02:43:11 myhost kernel: free:1973 free_pcp:0 free_cma:0
Mar 7 02:43:11 myhost kernel: Node 0 DMA free:3944kB min:60kB low:72kB high:88kB active_anon:0kB inactive_anon:0kB active_file:28kB inactive_file:32kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:15992kB managed:15908kB
mlocked:0kB dirty:0kB writeback:0kB mapped:0kB shmem:0kB slab_reclaimable:72kB slab_unreclaimable:236kB kernel_stack:48kB pagetables:60kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_tmp:0kB pages_scanned:36
0 all_unreclaimable? yes
Mar 7 02:43:11 myhost kernel: lowmem_reserve[]: 0 972 972 972
Mar 7 02:43:11 myhost kernel: Node 0 DMA32 free:3948kB min:3956kB low:4944kB high:5932kB active_anon:60kB inactive_anon:72kB active_file:0kB inactive_file:0kB unevictable:0kB isolated(anon):0kB isolated(file):0kB present:1032064kB manag
ed:999552kB mlocked:0kB dirty:12kB writeback:104kB mapped:32kB shmem:4kB slab_reclaimable:7120kB slab_unreclaimable:14460kB kernel_stack:2112kB pagetables:2948kB unstable:0kB bounce:0kB free_pcp:0kB local_pcp:0kB free_cma:0kB writeback_t
mp:0kB pages_scanned:792 all_unreclaimable? yes
Mar 7 02:43:11 myhost kernel: lowmem_reserve[]: 0 0 0 0
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
Mar 7 02:43:11 myhost kernel: 71 total pagecache pages
Mar 7 02:43:11 myhost kernel: 42 pages in swap cache
Mar 7 02:43:11 myhost kernel: Swap cache stats: add 245190, delete 245148, find 77026/136093
Mar 7 02:43:11 myhost kernel: Free swap = 3118172kB
Mar 7 02:43:11 myhost kernel: Total swap = 3334140kB
Mar 7 02:43:11 myhost kernel: 262014 pages RAM
Mar 7 02:43:11 myhost kernel: 0 pages HighMem/MovableOnly
Mar 7 02:43:11 myhost kernel: 8149 pages reserved
Mar 7 02:43:11 myhost kernel: [ pid ] uid tgid total_vm rss nr_ptes nr_pmds swapents oom_score_adj name
Mar 7 02:43:11 myhost kernel: [ 2054] 0 2054 5101 1 15 4 283 0 upstart-udev-br
Mar 7 02:43:11 myhost kernel: [ 2063] 0 2063 12362 1 28 4 184 -1000 systemd-udevd
Mar 7 02:43:11 myhost kernel: [ 3342] 102 3342 9780 1 23 3 89 0 dbus-daemon
Mar 7 02:43:11 myhost kernel: [ 3423] 0 3423 10864 1 26 3 85 0 systemd-logind
Mar 7 02:43:11 myhost kernel: [ 3441] 0 3441 15344 0 34 3 184 -1000 sshd
Mar 7 02:43:11 myhost kernel: [ 3450] 0 3450 4786 0 14 3 43 0 atd
Mar 7 02:43:11 myhost kernel: [ 3451] 0 3451 5915 0 17 4 65 0 cron
Mar 7 02:43:11 myhost kernel: [ 3457] 101 3457 63962 0 28 3 202 0 rsyslogd
Mar 7 02:43:11 myhost kernel: [ 3516] 0 3516 3919 1 13 3 156 0 upstart-file-br
Mar 7 02:43:11 myhost kernel: [ 3518] 0 3518 4014 0 13 3 265 0 upstart-socket-
Mar 7 02:43:11 myhost kernel: [ 3557] 0 3557 66396 0 32 3 1802 0 fail2ban-server
Mar 7 02:43:11 myhost kernel: [ 3600] 0 3600 3956 1 13 3 39 0 getty
Mar 7 02:43:11 myhost kernel: [ 3601] 0 3601 3198 1 12 3 37 0 getty
Mar 7 02:43:11 myhost kernel: [ 3673] 0 3673 26411 1 55 3 252 0 sshd
Mar 7 02:43:11 myhost kernel: [ 3740] 1000 3740 26411 1 52 3 253 0 sshd
Mar 7 02:43:11 myhost kernel: [ 3741] 1000 3741 5561 0 16 3 431 0 bash
Mar 7 02:43:11 myhost kernel: [ 3820] 103 3820 7863 1 21 3 152 0 ntpd
Mar 7 02:43:11 myhost kernel: [ 3837] 1000 3837 31990 0 58 4 12664 0 memcheck-amd64-
Mar 7 02:43:11 myhost kernel: [ 3841] 1000 3841 32006 0 59 4 12812 0 memcheck-amd64-
Mar 7 02:43:11 myhost kernel: [ 3844] 1000 3844 31950 0 57 4 12035 0 memcheck-amd64-
Mar 7 02:43:11 myhost kernel: [ 3849] 1000 3849 31902 0 56 4 11482 0 memcheck-amd64-
Mar 7 02:43:11 myhost kernel: [ 3853] 1000 3853 1087 0 7 3 27 0 lsof
Mar 7 02:43:11 myhost kernel: [ 3854] 0 3854 26140 5 55 3 230 0 sshd
Mar 7 02:43:11 myhost kernel: [ 3855] 104 3855 15699 0 33 3 202 0 sshd
Mar 7 02:43:11 myhost kernel: Out of memory: Kill process 3841 (memcheck-amd64-) score 11 or sacrifice child
Mar 7 02:43:11 myhost kernel: Killed process 3841 (memcheck-amd64-) total-vm:128024kB, anon-rss:0kB, file-rss:0kB
Это / proc / meminfo
MemTotal: 1015460 kB
MemFree: 277508 kB
MemAvailable: 322032 kB
Buffers: 8336 kB
Cached: 42208 kB
SwapCached: 46088 kB
Active: 58844 kB
Inactive: 116100 kB
Active(anon): 34784 kB
Inactive(anon): 89620 kB
Active(file): 24060 kB
Inactive(file): 26480 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 3334140 kB
SwapFree: 3215756 kB
Dirty: 16 kB
Writeback: 0 kB
AnonPages: 121128 kB
Mapped: 15072 kB
Shmem: 4 kB
Slab: 22668 kB
SReclaimable: 8028 kB
SUnreclaim: 14640 kB
KernelStack: 2016 kB
PageTables: 2532 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 3841868 kB
Committed_AS: 380460 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 0 kB
VmallocChunk: 0 kB
DirectMap4k: 14208 kB
DirectMap2M: 1034240 kB
DirectMap1G: 0 kB
all_unreclaimableда). Это страницы, заблокированные в ОЗУ, как правило, потому что они закреплены или используются ядром. Ничто из того, что вы оставили в оперативной памяти, не могло быть заменено в то время; все, что могло быть заменено, уже было. Опять же, решение больше оперативной памяти.Ответы:
Это кажется проблемой в сочетании двух факторов:
Это частично одна из строк, которая описывает, почему это происходит:
Другая строка такова:
| Первая строка - маска GFP, назначенная для распределения. Это в основном описывает то, что ядру разрешено / запрещено делать для удовлетворения этого запроса. Маска указывает на набор стандартных флагов. Последний бит «2» указывает на то, что выделение памяти должно происходить из
HighMemзоны.Если вы внимательно посмотрите на вывод OOM, вы увидите, что никакой
HighMem/Normalзоны на самом деле не существует.HighMem(обычно такжеNormalвызывается на x86_64) имеет тенденцию отображать память для зон за пределами стандартных диапазонов 896MiB, напрямую доступных ядру в 32-битных системах. На x86_64HighMem/Normalпохоже охватывает все страницы размером выше 3GiB.DMA32содержит зону, используемую для памяти, которая будет доступна на 32-битных устройствах DMA, то есть вы можете обращаться к ним с помощью 4-байтовых указателей. Я считаю,DMAчто для 16-битных устройств DMA.Вообще говоря, систем с малой памятью
Normalне существует, учитывая, что онаDMA32охватывает все доступные виртуальные адреса.Причина, по которой вы убиваете OOM, заключается в том, что для
HighMemзоны доступно 0 страниц. Учитывая, что у обработчика нехватки памяти нет абсолютно никакого способа удовлетворить необходимость использования страниц в этой зоне путем замены, уничтожения других процессов или любого другого трюка, OOM-killer просто убивает его.Я полагаю, что это вызвано раздутием виртуальной машины при загрузке. В системах KVM можно установить два значения.
Это работает так, что вы можете оперативно добавлять память на сервер до доступной памяти. Ваша система, однако, фактически получает текущую память.
Когда виртуальная машина KVM загружается, она запускается с максимально возможным выделением памяти (доступной памяти). Постепенно на этапе загрузки системы KVM восстанавливает эту память, используя ее всплывающее окно, оставляя вместо этого текущие настройки памяти, которые у вас есть.
Это мое убеждение, вот что здесь произошло. Линод позволяет вам расширить память, давая вам гораздо больше при запуске системы.
Это означает, что
Normal/HighMemв начале времени жизни системы есть зона. Когда гипервизор раздувает его, нормальная зона по праву исчезает из диспетчера памяти. Но я подозреваю, что флаг, указывающий, доступна ли указанная зона для выделения, не очищается, когда это необходимо. Это приводит к тому, что ядро пытается выделить из зоны, которая не существует.С точки зрения решения этой проблемы у вас есть два варианта.
Включите это в списки рассылки ядра, чтобы увидеть, действительно ли это ошибка, ожидаемое поведение или вообще ничего общего с тем, что я говорю.
Попросите, чтобы линода установила для «доступной памяти» в системе то же назначение в 1 ГБ, что и для «текущей памяти». Таким образом, система никогда не всплывает и никогда не получает нормальную зону при загрузке, сохраняя флаг чистым. Удачи им в этом!
Вы должны быть в состоянии проверить, что это так, установив собственную виртуальную машину в настройке KVM, доступную для 6 ГБ, текущую на 1 ГБ и запустив тест с использованием того же ядра, чтобы увидеть, происходит ли это поведение, которое вы видите выше. Если это так, измените настройку «Доступно», чтобы она равнялась току 1 ГБ, и повторите тест.
Я делаю кучу образованных догадок и читаю между строк что-то, чтобы придумать этот ответ, но то, что я говорю, кажется, соответствует уже изложенным фактам.
Я предлагаю проверить свою гипотезу и дать всем нам знать результат.
источник
Чтобы ответить на ваш
oom_score_adjглавный вопрос, используйте (kernel> = 2.6.36) или для более ранних версий ядра (> = 2.6.11)oom_adj, смотрите man procЕсть еще много чего почитать, но установка oom_score_adj в -1000 или oom_adj в -17 даст то, что вы хотите.
Беда в том, что что-то еще будет убито. Возможно, было бы лучше определить, почему OOM вызывается, и разобраться с этим.
источник
Несколько мыслей (из моих комментариев выше) и ссылки на интересные материалы о вашей ситуации:
Я рекомендую вам убедиться в том, что 1) вы можете использовать более 3 000 гигабайт в своем текущем ядре и конфигурации (& cpu) [потому что, если 3Gb является пределом для вашей системы и операционной системы, вы превышаете его]. 2) что вы разрешаете обмен, и подсистема обмена работает и работает. удачи (я не буду объяснять как, так как это зависит от ваших настроек и специфики. Поисковые системы помогут). И что вы не переполняете таблицу ядра (nb pids? Или что-то еще (некоторые могут быть установлены во время компиляции ядра).
Проверьте, что все это (аппаратное обеспечение, или смоделированное оборудование vm и т. Д.) - 64 бита. (см., например: /ubuntu/313379/i-installed-a-64-bit-os-in-a-32-bit-processor/313381 ). Все подсистемы cpu & host OS & vm & vm OS должны быть 64-битными, иначе у вас не будет реального 64-битного vm
Некоторые хорошие чтения:
и, наконец, http://www.oracle.com/technetwork/articles/servers-storage-dev/oom-killer-1911807.html показывает способ предотвращения нацеливания вашего процесса на убийцу оом! (
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 )vm.min_free_kbytes, чтобы всегда поддерживать физическую оперативную память свободной и, таким образом, уменьшить вероятность того, что OOM потребуется что-то убить (но не переусердствуйте, так как OOM мгновенно)vm.swappinessдо 100 (чтобы ядро было проще менять )Обратите внимание, что если у вас слишком мало памяти для выполнения поставленной задачи, даже если вы не используете OOM, она может (или не может) стать ОЧЕНЬ медленной - полчаса (в системе с достаточным объемом ОЗУ) может легко занять несколько недель ( когда оперативная память заменена на swap), чтобы завершить в крайнем случае, или даже повесить всю виртуальную машину Это особенно актуально, если подкачка происходит на классических ротационных дисках (в отличие от твердотельных накопителей) из-за массовых случайных операций чтения / записи, которые очень дороги для них.
источник
Я бы попробовал включить overcommit и посмотреть, поможет ли это. Кажется, что ваш процесс завершается с ошибкой внутри
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 ГБ. Конечно, некоторые типы программного обеспечения mlock - это куча оперативной памяти, но в моем случае (поскольку я использую одно и то же программное обеспечение только на другом ядре), это явно не тот случай.
источник