Процесс JVM убит ОС - PullRequest
Новая
       18

Процесс JVM убит ОС

0 голосов
/ 23 августа 2011

Я реализовал веб-сервис, используя компонент Jetty Camel через Akka (конечная точка), который перенаправляет полученные сообщения в пул актеров с настройкой: 

   def receive = _route()
   def lowerBound = 5
   def upperBound = 20
   def rampupRate = 0.1
   def partialFill = true
   def selectionCount = 1
   def instance() = Actor.actorOf[Processor]

И Processor - это класс, который обрабатывает полученное сообщение и отвечает с результатом процесса. Приложение работало нормально и безупречно на моем локальном компьютере, однако после его развертывания на микроэкземпляре EC2 (512 м памяти - CentOS, как ОС) ОС (oom-killer) убивает процесс из-за OutOfMemory (не JVM OOM) после того, как 30 звонков или около того (независимо от частоты звонков).

Профилирование приложения локально не показывает каких-либо значительных утечек памяти, если они вообще существуют. Из-за некоторых трудностей я не смог выполнить правильное профилирование на удаленной машине, но, наблюдая за выводом «top», я заметил кое-что интересное: свободная память остается около 400 МБ после инициализации приложения, после чего она отскакивает от 380 МБ до 400 МБ, что кажется довольно естественно (gc, и т. д.). Но интересно то, что после получения 30-го или около того звонка он внезапно переходит оттуда к 5 Мб свободной памяти, а бум убивается. Журнал oom-killer в / var / log / messages подтверждает, что это было сделано ОС из-за нехватки памяти / свободного обмена.

Теперь это не совсем относится к Akka, но я наконец решил, что должен посоветоваться с вами, ребята, после 3 дней безнадежной борьбы.

Спасибо за любые предложения.

Ответы [ 2 ]

1 голос
/ 01 февраля 2014

Мое общее замечание состоит в том, что JVM использует много памяти помимо кучи Java.Я не знаю точно, для чего, но могу только предположить, что он мог бы использовать обычную кучу Си для компиляции или хранения скомпилированного кода или других вещей permgen или еще чего-нибудь.В любом случае, мне было трудно контролировать его использование.

Если вы не слишком загружены дисковым хранилищем, вы можете просто создать файл подкачки размером в ГБ или два, чтобы у JVM было местопереполнить.По моему опыту, память, которую он использует за пределами кучи Java, в любом случае не слишком часто используется и может просто лежать без проблем, не вызывая большого количества операций ввода-вывода.

1 голос
/ 01 февраля 2014

Я заметил, что когда создается много мелких объектов, которые должны быть немедленно собраны, мусор Java-процесса уничтожается.Возможно, потому что предел памяти достигнут до того, как GC восстановит временные объекты .

Попробуйте запустить его с одновременной меткой и очистить сборщик мусора: 

java -XX:+UseConcMarkSweepGC
...