Мы запускаем 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 с помощью собственного программного обеспечения для мониторинга процессов. (взгляните на Монит)
Удачи
Виртуальные машины RHEL4, на которых запущен Oracle / Java, случайным образом завершают процессы убийцей OOM Подробности Убийца OOM убивает приложения, даже если ESX не загружен памятью. Верхняя часть команды показывает, что кэшируется много памяти, а подкачка почти не используется. Решение
Когда размер копируемых данных превышает размер физической памяти, oom-killer запускает случайное завершение процессов.
Это можно исправить, запустив:
sysctl -w vm.lower_zone_protection 100
Когда для lower_zone_protection установлено значение 100, он увеличивает порог свободных страниц на 100, тем самым запускает восстановление страниц раньше и предотвращает отставание NFS (сетевой файловой системы) от требований ядра к памяти. Это приводит к тому, что восстановление страницы происходит раньше, что обеспечивает большую «защиту» для зон. Эта проблема обнаружена в RHEL компанией Redhat, и они предоставили обходной путь в следующих статьях: