Out of Memory: Kill process и "кома"

[rey]

Всем привет!

Progress 9.1D , os Slaсkware 12 (2.6 ядро), ram 16 гигов, 400 - 500 self-service клиентов, база 48 гигов.

Решил увеличить количество буферов (-B), было 110000 (размер shared memory ~ 500 м) ,чудесным параметром kernel.shmmax равным
134217728 добился того что при 21 сегменте, позволенном для моей версии Progressa,размер shared memory стал 2,7 гига. Но радость была недолгой... через полчаса при 200 - 230 клиентах сервер ушел в кому (кроме пинга никакой реакции, в консоли только написал "root" и нажал на "enter"...и тоже ничего), только "reset" и оставался.. уменьшил количество буферов (до размера shared memory ~ 1,8 гига) и опять тоже самое , лишь период работы до комы немного увеличился...

Вот немного из вывода vmstata при "коме"
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
0 6 0 3116508 616 12067548 0 0 31 8 120 1263 0 0 2 98
0 6 0 3116436 616 12067548 0 0 28 8 122 1247 0 0 2 98
0 6 0 3116416 616 12067548 0 0 29 11 124 1241 0 0 1 98
0 5 0 3116412 616 12067548 0 0 27 8 117 1215 0 0 2 98
0 6 0 3116472 616 12067548 0 0 28 8 118 1169 0 0 2 98
1 5 0 3116416 616 12067548 0 0 28 8 118 1332 0 0 2 98
0 6 0 3116412 616 12067548 0 0 27 8 118 1312 0 0 2 98
3 5 0 3116348 616 12067548 0 0 28 9 118 1292 0 0 2 98

в syslog обнаружил такие строки, по времени появившиеся именно во время "комы"

Feb 4 18:54:20 ss02 kernel: Out of Memory: Kill process 8360 (_progres) score 747708 and children.
Feb 4 18:54:20 ss02 kernel: Out of memory: Killed process 8360 (_progres).
Feb 4 18:54:20 ss02 kernel: oom-killer: gfp_mask=0x84d0, order=0
Feb 4 18:54:20 ss02 kernel: <c01323f8> out_of_memory+0x28/0x94 <c0133372> __alloc_pages+0x1e8/0x26c
Feb 4 18:54:20 ss02 kernel: <c010fd5f> pte_alloc_one+0x11/0x12 <c0138dbf> __pte_alloc+0x10/0x96
Feb 4 18:54:20 ss02 kernel: <c013b325> __handle_mm_fault+0x8f/0x215 <c0110386> do_page_fault+0x2ac/0x611
Feb 4 18:54:20 ss02 kernel: <c01100da> do_page_fault+0x0/0x611 <c0103087> error_code+0x4f/0x54

записей касаемых процессов _progres было множество , но у всех причина почему их убили - Out of Memory.

Как видно из vmstat , память то есть, свап даже нетронут, но почему Out of memory????

Кстати такое случалась и ранее, со старым значением kernel.shmmax, которое позволяло создать лишь ~500 м shared memory (при 118000 буферов), но при очень интенсивной нагрузке (когда закрывали месяц, делали отчеты и т.п.)

Смутно подозреваю что дело тут из области kernel tune, но может я и неправ.
Может кто нибудь сталкивался с таким?

[Arelav]

[Arelav]

[Reply]

[Arelav]

[rey]

Спасибо всем кто ответил!
Arelav с первой ссылки посмеялся , однако... Над второй задумался, попробую поиграть с overcommit_memory, о результатах напишу обязательно.
Reply, мне так кажется что дело всетаки не в работе с диском или с рейдом, а скорее с менеджером памяти и ядром. Кстати о "коме" ,у вас тоже были сообщения в системных логах об ООМ киллере и Out of Memory???
Комрады , у кого ядро 2.6 и все работает без "ком" даже в пики нагрузки, киньте плз на мыло вывод sysctl -a ,особо интересуют разделы kernel и vm,если не трудно alkorey@rambler.ru . Заранее благодарен!

[Arelav]

[rey]

Спасиб Arelav ! Увы ,приходится иногда эксперементить . Я исхожу из того что ядро 2.6 на самых разных дистрибутивах врядли работает радикально иначе, а вот в моем случае могут стоять и мешать работе какие нибудь дефолтные настройки (например тот же overcommit_memory или shmmax) . Но все подряд ,действительно, не стоит копировать .

[apotokin]