fork: Cannot allocate memory

OS, ядро, dmesg, сколько процессов ? Может баг в ядре который ребутом полечится

А процессов сколько?

Debian 7.11 3.2.0-4-amd64 процессов 146 в dmesg чисто, ребут был.

/proc/meminfo и /proc/sys/vm/overcommit_memory покажи

3.2.0 - както стремно (уже 84 багфикса было для 3.2 ветки).

А что в /proc/slabinfo ? И сколько всего потоков ?

у тебя что-то из лимитных вещей закончилось. Возможно дескрипторы или что-то подобное.

cat /proc/sys/vm/overcommit_memory
0

cat /proc/meminfo
MemTotal:       32878740 kB
MemFree:        22344460 kB
Buffers:           59612 kB
Cached:          6190060 kB
SwapCached:            0 kB
Active:          7434060 kB
Inactive:        2468708 kB
Active(anon):    3653680 kB
Inactive(anon):      216 kB
Active(file):    3780380 kB
Inactive(file):  2468492 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:      16768892 kB
SwapFree:       16768892 kB
Dirty:              1056 kB
Writeback:             0 kB
AnonPages:       3653124 kB
Mapped:            37816 kB
Shmem:               776 kB
Slab:             207824 kB
SReclaimable:      64052 kB
SUnreclaim:       143772 kB
KernelStack:      260312 kB
PageTables:        81440 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:    33208260 kB
Committed_AS:   38256032 kB
VmallocTotal:   34359738367 kB
VmallocUsed:      133824 kB
VmallocChunk:   34359604315 kB
HardwareCorrupted:     0 kB
AnonHugePages:         0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB
DirectMap4k:       57344 kB
DirectMap2M:     2971648 kB
DirectMap1G:    30408704 kB

Окей, а теперь покажи пожалуйста ulimit -a

ulimit -a
core file size          (blocks, -c) 0
data seg size           (kbytes, -d) unlimited
scheduling priority             (-e) 0
file size               (blocks, -f) unlimited
pending signals                 (-i) 256759
max locked memory       (kbytes, -l) 64
max memory size         (kbytes, -m) unlimited
open files                      (-n) 1024
pipe size            (512 bytes, -p) 8
POSIX message queues     (bytes, -q) 819200
real-time priority              (-r) 0
stack size              (kbytes, -s) 8192
cpu time               (seconds, -t) unlimited
max user processes              (-u) 256759
virtual memory          (kbytes, -v) unlimited
file locks                      (-x) unlimited

Хм, тоже вроде никакого криминала(у меня например, некоторые параметры даже ниже по дефолту). Ну и наконец выхлоп ps aux на какой-нибудь pastebin бы не помешал

Update: вот тут чуть подробнее расписали возможные проблемы

CommitLimit:    33 208 260 kB
Committed_AS:   38 256 032 kB

Ищите процесс (процессы) которые запросили большое количество RAM (можно в top Shift+M и смотреть у кого большой VIRT)

Вообще не интересно самый жирный это

ps --sort -rss  -eo rss,vsz,pid
  RSS    VSZ   PID
2607036 36728164 21776
577652 1102564 24494
144836 544060 2921
101856 1521132 21755
67732 2613624 25743
11392 162992  2307
 9216 163452  4261

И кто у нас 21776? Чинится ли всё, если его прибить?

Насколько я понял 21776 процесс запросил 36G RAM

Да действительно прибил 21776 и все наладилось. Но вот что странно запросил он 35.0g а использовал всего 2.5g. Притом своп пустой на запросы памяти сыпется Cannot allocate memory. Почему?

Есть подозрение что дело в overcommit и бажном процессе, который сделал malloc на overдохрена памяти

top - 21:32:03 up 5:36, 2 users, load average: 0.14, 0.19, 0.18
Tasks: 138 total, 1 running, 137 sleeping, 0 stopped, 0 zombie
%Cpu(s): 13.5 us, 0.8 sy, 0.0 ni, 85.3 id, 0.2 wa, 0.0 hi, 0.1 si, 0.0 st
KiB Mem: 32878740 total, 10601464 used, 22277276 free, 62572 buffers
KiB Swap: 16768892 total, 0 used, 16768892 free, 6246996 cached

  PID USER      PR  NI  VIRT  RES  SHR S  %CPU %MEM    TIME+  COMMAND                                                                                                                                       
21776 xxxxxxxx  20   0 35.0g 2.5g  14m S  91.9  7.9  63:55.98 xxxx                                                                                                                                          
24494 xxxxxxxx  20   0 1076m 564m  14m S   0.7  1.8  12:18.24 xxxx                                                                                                                                          
 2921 xxxxx     20   0  531m 141m 8036 S  19.4  0.4  25:01.12 xxxxxx                                                                                                                                        
21755 xxxxxxxx  20   0 1485m 100m  12m S   0.0  0.3   0:19.52 xxxx                                                                                                                                          
25743 xxxxxxxx  20   0 2552m  66m  13m S   0.3  0.2   0:31.57 xxxx                                                                                                                                          
 2307 xxxx      20   0  159m  11m 4988 S   0.0  0.0   0:01.44 xxxxxxx                 

COMMAND                                                                                                                                       
xxxx

Это ты шифруешься так, что ли? Я понимаю там логины пользователей еще скрывать, но что у тебя такого сверхсекретного в именах процессов? :-)

И еще, ты так и не ответил что именно за процесс был под pid 21776.

Логично. Процесс кривой но нужный, раньше столько МЕМа не заказывал.

Это что бы холивар не разводить... Java это была java :)))

Не дай бохъ узнают, шо java (подкодит по кол-ву символов) крутит. ;)

Вариантов тут немного: либо фиксить поведение процесса(патчить, писать багрепорты и/или накатывать новую версию), либо переключать overcommit в режим 2.

ОСТОРОЖНО: неправильные настройки overcommit могут к чертям сломать тебе систему, пока не откатишь в зад. Например, у меня при дефолтных 50% overcommit_ratio на десктопе с 4G RAM напрочь отказывались запускаться ЛЮБЫЕ приложения на java(даже hello world).

Update: гы, как в воду глядел, начал писать коммент до того как увидел инфу про java :)

Крути настройки GC в java, ну или overcommit, но осторожно и желательно с локальным доступом(хотя SSH по идее прибивается OOM-Killer-ом в сааамую последнюю очередь, так что...)

I know it! ;)

Ещё правильней — настоить ulimits — кривые приложения должны падать (пока их не починят).

С лимитами там печально всё ЕМНИП, нормально через /etc/security/limits.conf потребление памяти на пользователя не зарезать, тут нужны cgroups. На самом деле ничего страшного - у нас так на работе ограничена память, которую может сожрать пых и апач на серваке веб-разработчиков - любят они её съедать с концами :-)

Причем, т.к. рожается немаленькое количество процессов - OOM Killer тупо не успевает всё это прибить и система стоит раком. Ну точнее стояла, пока не ворвались мы с напарником и не вкрутили cgroups c потолком на 80% памяти сервера

Насколько я понял что в новых ядрах через ulimits не ограничить потребление памяти.

Да, это лучше делать через cgroups

Пример для CentOS. На свой дистр я надеюсь нагуглишь сам.

Что прикольно - можно ограничить по памяти все процессы с определенным именем, не важно от какого пользователя они запущены. Очень нужная штука в случае web-сервера, где virtualhost-ы раскиданы по разным UID

Для будующих поколений: похожие проблемы в BSD решаются элементарно через login.conf.

Потомучто у вас стоит лимит в 32G на выделеную память, это настраивается через параметры

/proc/sys/vm/overcommit_memory - режим лимита
/proc/sys/vm/overcommit_ratio - лимит в % от физической RAM (+ свап)

Можно либо поднять /proc/sys/vm/overcommit_ratio (скажем до 200%) либо установить 1 режим (echo 1 > /proc/sys/vm/overcommit_ratio) и отключить лимитирование по резервированию вообще

java

Тогда наверное стоит параметрами самой JVM ограничить размер RAM чтобы оставалось пару G для системы.

То-то и он что для java стоит -Xms1024M -Xmx2048M

То-то и он что для java стоит -Xms1024M -Xmx2048M

Это гдето в настройках или видно в /proc/<pid>/cmdline ? И какой размер стека (-Xss) и сколько потоков (ls /proc/<pid>/status | grep Thread) ?

Потоков многовато

cat /proc/810/status | grep Thread
Threads:	23690

Xss по дефолту вроде 2M а 23690 потоков это уже 46G для стека