Я периодически не отвечаю на запросы в tomcat в нашей производственной среде. Я не могу воспроизвести это в тестовой среде, и ничего не отображается в журналах до или во время события. Tomcat продолжает работать, но перестает обслуживать запросы. я прочел эта тема и разместили параметры вывода сборки мусора в JAVA_OPTS, хотя мне еще предстоит перезапустить tomcat, чтобы они вступили в силу. Моя ситуация отличается тем, что tomcat / jvm, по-видимому, не восстанавливается и не "просыпается". Я неоднократно подтверждал, что наше приложение не отвечает в течение как минимум 15 минут. Решение - всегда перезапускать tomcat (с помощью daemontools). Частота варьируется, иногда во время пиковой нагрузки, а иногда и посреди ночи (очень легкая нагрузка).
Я выделил до 4 ГБ памяти для jvm (-Xms2g -Xmx4g). Сервер имеет 16 ГБ памяти и работает под управлением 64-разрядной jvm. Технический документ Sun в заявлении о настройке Java: «Выделение слишком большого количества физической памяти системы может привести к подкачке виртуальной памяти на диск, что весьма вероятно во время операций по сборке мусора, что приведет к значительным проблемам с производительностью». Я устанавливаю слишком большой размер кучи? Будет ли мне полезно установить минимальный размер таким же, как максимальный?
Я не верю, что система переключает память на диск. Вывод команды free -m показывает отсутствие использования подкачки, и я установил для swappiness значение 0 в системе.
Когда сегодня утром в 2:30 утра произошел отказ от ответа, я запустил быстрый jstat и ps перед перезапуском tomcat:
jstat показал те же значения, что и сейчас, за некоторыми исключениями: YGC было 431 против 44 сейчас, YGCT 10/1, FGC 59/7, FGCT 39/2, GCT 49/3
Вывод команды ps показал использование 1422832 резидентной и 5723580 виртуальной памяти. Для сравнения: 1390036 и 5642668, полученные вчера во время нормальной работы.
Я ни в чем не разбираюсь, поэтому любая помощь будет принята с благодарностью.
ОБНОВИТЬ: Хорошо, я добавил следующее в JAVA_OPTS и на мгновение перезапустил tomcat:
-XX: + UseConcMarkSweepGC -Xms2g -Xmx2g -verbose: gc -XX: + PrintGCTimeStamps -XX: + PrintGCDetails
Изменения: 1) алгоритм swich gc. 2) уменьшите максимальный размер кучи, так как, кажется, мне не нужен 4g, и, по-видимому, чрезмерное использование может вызвать периодический массивный gc. 3) Включите ведение журнала vebose gc. Спасибо всем.
Для начала вот полезная ссылка на «Настройка сборки мусора с помощью виртуальной машины Java TM 5.0»
Это действительно похоже на паузу GC, из-за которой tomcat не отвечает. Для начала стоит воспользоваться сборщиком мусора "низкая пауза" с опцией -XX:+UseConcMarkSweepGC.
Мы видели это в нашей производственной среде несколько раз, и в конечном итоге это закончилось тем, что сборщик мусора Java остановил дальнейшие запросы. Самым большим показателем для нас было 100% использование процессора по крайней мере на одном из ядер в течение периода отсутствия ответов.
В нашем случае ответ состоял в том, чтобы отследить утечку памяти в приложении. Я не уверен, что это считается для вас ответом, но это, по крайней мере, еще одна точка данных.