Назад | Перейти на главную страницу

OOM-Killer, jboss и паника ядра

Мы запускаем RedHat 3.4.6 (x32) на VMWareEsx3.5 (x64) с 6 ГБ ОЗУ. Некоторые java-процессы (включая jboss) работают в фоновом режиме.

Проблема в том, что java-процессы потребляют много памяти, и иногда их убивает OOM-killer. Когда OOM-killer вот-вот начнет действовать, свободной физической памяти будет очень мало 100-200 МБ, но своп не используется (99% свободного места). Иногда это также вызывает панику ядра.

Спасибо

Лично я бы никогда не стал использовать PAE (более 4G RAM в 32-битной системе). У вас будет намного больше возможностей использовать настоящее 64-битное ядро ​​и систему.

OOM должен срабатывать только тогда, когда может произойти сбой malloc. (не когда у вас доступно много свопа)

32-битное ядро, вероятно, является частью причины. PAE использует разные зоны памяти, и может случиться так, что одна зона не может быть перенесена из другой.

Вы изменили свою подкачку? (Насколько легко ядро ​​будет использовать подкачку.) Cat / proc / sys / vm / swappiness?

Вы также можете изучить настройку vm.dirty_ratio или vm.lower_zone_protection = 100.

Вы уловили панику ядра? (последовательная консоль часто является хорошим способом сделать это)

Вы также можете попытаться вытеснить OOM-Killer с помощью собственного программного обеспечения для мониторинга процессов. (взгляните на Монит)

Удачи

Из http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1002704

Виртуальные машины RHEL4, на которых запущен Oracle / Java, случайным образом завершают процессы убийцей OOM Подробности Убийца OOM убивает приложения, даже если ESX не загружен памятью. Верхняя часть команды показывает, что кэшируется много памяти, а подкачка почти не используется. Решение

Когда размер копируемых данных превышает размер физической памяти, oom-killer запускает случайное завершение процессов.

Это можно исправить, запустив:

sysctl -w vm.lower_zone_protection 100

Когда для lower_zone_protection установлено значение 100, он увеличивает порог свободных страниц на 100, тем самым запускает восстановление страниц раньше и предотвращает отставание NFS (сетевой файловой системы) от требований ядра к памяти. Это приводит к тому, что восстановление страницы происходит раньше, что обеспечивает большую «защиту» для зон. Эта проблема обнаружена в RHEL компанией Redhat, и они предоставили обходной путь в следующих статьях: