У меня есть два сервера, работающих в частном облаке vSphere, на обоих запущены JBoss и Tomcat.
Время от времени машина 8 перестает отвечать, и OOMKiller эффективно берет на себя управление машиной. Единственным вариантом была перезагрузка через консоль администратора vSphere.
Мы всегда предполагали, что ограничения Java-приложений (Xmx и т.д.) были слишком высокими. Поэтому после последнего перезапуска мы воспользовались возможностью уменьшить ограничения памяти для JVM и настроить некоторые сценарии, которые регистрируют определенную информацию.
На этот раз проблема, похоже, возникла на обеих машинах, хотя ведение журнала, относящееся к этой проблеме, было только на машине 8.
Интересно то, что использование свопа удваивается за минуту, а использование приложений Java - нет. К сожалению, наше ведение журнала было сосредоточено на JVM, поэтому мы не знаем, что на самом деле запрашивало всю эту память.
Вот журнал использования памяти до тех пор, пока машина не перестанет отвечать (воссоздана из журналов верхней информации для различных JVM):
Time Load Average Phys Used Virt Used
00:19:23 1,01 3016868 380872
00:20:27 3,44 3025136 435216
00:20:32 3,24 3029548 475548
00:21:37 3,51 3023888 864404
00:21:43 3,39 3030808 889608
Таким образом, использование виртуальной памяти увеличилось с 380 до 889 мегабайт менее чем за 2,5 минуты.
Я в курсе этот проблема, но не знаю, действительно ли это та же проблема - использование Java на нашей машине не кажется необоснованным, а машина, которая больше всего страдает от этой проблемы, находится на RHEL5.3.
Мы не активировали vm.lower_zone_protection вариант, предложенный в связанном вопросе.
Есть ли у кого-нибудь предложения или пояснения?
Кроме того, является ли тот факт, что машина 25 вышла из строя, также совпадением, или могут быть обстоятельства в vSphere, которые могут заставить их обоих реагировать таким образом?
Проблемы возникают из-за JVM. По сути, JVM «заранее выделяет» всю память, которую она хочет, но ядро фактически «передает» память JVM только тогда, когда она действительно нужна. Таким образом, вы можете очень быстро попасть в описываемую вами ситуацию (использование подкачки резко возрастает, убийца OOM приходит в неистовство) без «очевидного» использования памяти - потому что, в принципе, память уже «используется».
Решения включают настройку JVM, чтобы она не использовала столько памяти, отключение чрезмерной фиксации (не очень хорошая идея по причинам, которые я объяснил ранее), обеспечьте больший объем подкачки (машина замедлится до ползания, но не умрет, что даст вам возможность войти и изучить проблему «вживую») или просто дайте виртуальным машинам больше памяти. Достаточно дешево.