странная проблема с памятью out of memory

Логи ядра надо смотреть. Если превышены лимиты ulimits для пользователя под которым запускается программа то ядро Linux ее убивает, в журнале о сем создается запись.

Ну вот ulimit для работающего процесса.

cat /proc/29064/limits
Limit                     Soft Limit           Hard Limit           Units
Max cpu time              unlimited            unlimited            seconds
Max file size             unlimited            unlimited            bytes
Max data size             unlimited            unlimited            bytes
Max stack size            33554432             33554432             bytes
Max core file size        unlimited            unlimited            bytes
Max resident set          unlimited            unlimited            bytes
Max processes             1048576              1048576              processes
Max open files            8192000              8192000              files
Max locked memory         16777216             16777216             bytes
Max address space         unlimited            unlimited            bytes
Max file locks            unlimited            unlimited            locks
Max pending signals       255238               255238               signals
Max msgqueue size         819200               819200               bytes
Max nice priority         0                    0
Max realtime priority     0                    0
Max realtime timeout      unlimited            unlimited            us

Процессы запускаются в докере от рута. В логах по этому поводу ничего нет.

Не выключай полностью ipv6.

Он иногда нужен на интерфейсе lo

Загрузи ipv6, отключи на всех интерфейсах ipv6, кроме lo.

sysctl -w net.ipv6.conf.default.disable_ipv6=1
sysctl -w net.ipv6.conf.all.disable_ipv6=1
sysctl -w net.ipv6.conf.lo.disable_ipv6=0

А версия ядра какая?

4.15.0-66 пробовал с linux-image-5.3.0-19 вроде так же

с ipv6 попробую

Процессы запускаются в докере от рута.

Об докере ничего не скажу. Может проблема в нем, смотри логи докере.

В логах по этому поводу ничего нет.

Аудит в ядре линукса надо включить, в твоем случае необходимо:

CONFIG_GRKERNSEC_SIGNAL=y

sysctl -w kernel.grsecurity.signal_logging=1

Возможно еще и:

CONFIG_GRKERNSEC_FORKFAIL=y

sysctl -w kernel.grsecurity.forkfail_logging=1

Если в твоих исходниках ядра нет этих опций наложи патчи от grsecurity.net

Тогда в логах будет конкретно указано почему ядро убило процесс.

Интересно бы посмотреть на потребление памяти при работе процесса.

Возможно он при старте он использует значительно больше памяти.

Отсутствие swap дает максимально жесткую реакцию ядра не возможную нехватку памяти, а приложения частенько просят памяти значительно больше, чем реально используется.

Не смотрел VSZ и RSS в «ps axu» для запущеных приложений ?

Это проблема приложения, а не системы. Очевидно, это кривое приложение. Например https://stackoverflow.com/questions/37551288/golang-fatal-error-runtime-out-of-memory

И решается это исправлением приложения.

Еще вариант - разрешить оверкоммит, выставив его в единицу.

Процессы запускаются в докере от рута.

С какими лимитами запускается контейнер и как?

Каким-то образом это похоже что реально связано с оверкомитом.

root@node16 ~ # sysctl vm.overcommit_memory=2 vm.overcommit_memory = 2 root@node16 ~ # sysctl vm.overcommit_memory -bash: fork: Cannot allocate memory -bash: wait_for: No record of process 17554

При этом память в page cache есть и ее много, на этой ноде сейчас 128GB, в page cache 60GB, free 500MB

С vm.overcommit_memory = 1 похоже что работает, только ставлю 2, получаю Cannot allocate memory в том же bash процессе.

Похоже я как-то сам себя обманул, kubernetes сам ставит overcommit_memory - 1, я не помню почему решил ставить 2. Как-то он совсем не хочет отбирать память у page cache с 2, c 1 - ok.

Каков итог? Выставил все в 1, проблема решилась?

Кэш тут не причём. Когда ты отключаешь оверкоммит, ты сталкиваешься с той проблемой, из-за которой его придумали: адресного пространства используется гораздо больше, чем реальной памяти.

Когда ты отключаешь оверкоммит, ты сталкиваешься с той проблемой

• cannot allocate memory

адресного пространства используется гораздо больше, чем реальной памяти.

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

А проблему нехватки реальной решают ООМ киллеры - ядерный и юзерспейсные.

оно съедает память из free но buff/cache не трогается Такого быть не может. Местные афторитеты тут недавно это объясняли. Зачем ты врёшь?

Swap выключен

98%, что проблема в этом, даже если памяти вроде бы хватает.

Выставил в 1 и проблема пока не повторялась. Наблюдаю дальше.

Клован, плез. Он отрубил оверкоммит, потому всё и убивается при свободной памяти. Кэш тут непричём.