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

Question 1

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

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

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

Изменили ли вы swappiness? (Насколько легко ядро будет использовать swap.) cat /proc/sys/vm/swappiness ?

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

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

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

Удачи

Answer

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

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

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

Изменили ли вы swappiness? (Насколько легко ядро будет использовать swap.) cat /proc/sys/vm/swappiness ?

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

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

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

Удачи

Question 2

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

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

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

Это можно исправить, выполнив:

sysctl -w vm.нижняя_зона_защиты 100

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

Answer