Почему JVM этих серверов Tomcat выполняет полный GC почасово?
Мы запускаем много серверов Tomcat и наблюдаем, что полные сборки мусора (GC) часто выполняются на почасовой основе, особенно когда использование памяти относительно невелико. Точное время похоже на время запуска сервера приложений; если сервер запущен в 01:13, полный GC будет выполнен в 02:13, а следующий полный GC появится в 03:13. Я не смог найти документацию, чтобы объяснить это поведение.
Это проблема, потому что одновременно запускался пул серверов, и все они одновременно работают с полными GC. Если задержка GC достаточно длинная, чтобы заставить балансировщик нагрузки отмечать сервер как нисходящий, все приложение может отключиться в течение некоторого времени. Было бы лучше, если бы полные GC могли быть распределены в течение периода, поэтому никакие два сервера не выполняли полный GC одновременно, но я не могу найти способ контролировать это поведение.
Кто-нибудь еще видел это поведение? Есть ли способ влиять, когда происходят эти "регулярные" полные GC?
Ответы
Ответ 1
Ваши "обычные" почасовые GC, вероятно, связаны с этой известной ошибкой, JreMemoryLeakPreventionListener вызывает полный GC каждый час, когда gcDaemonProtection = истина".
Подтвердите свои версии Tomcat и значение свойства gcDaemonProtection
вашего JreMemoryLeakPreventionListener
(по умолчанию true
).
Патч предположительно включен в Tomcat v.7.0.28 + и v.6.0.36 +.
Либо обновите свой сервер (ы), либо выберите решение без обновления от здесь, в виде:
- запретить сбор всех мусора с помощью JVM arg
-XX:+DisableExplicitGC
- сохранить полные GC, но отложить до CMS-коллектора, используя JVM arg
-XX:+ExplicitGCInvokesConcurrent
- set
<Listener className="org.apache.catalina.core.JreMemoryLeakPreventionListener"
gcDaemonProtection="false"/>
- Отключить прослушиватель
Кредит, в котором должен быть предоставлен кредит; Я получил свой первоначальный ответ от здесь.
Ответ 2
вы можете изменить интервал на
-Dsun.rmi.dgc.client.gcInterval=60000
-Dsun.rmi.dgc.server.gcInterval=60000
взгляните сюда
https://docs.oracle.com/cd/E19199-01/817-2180-10/pt_chap5.html