В нашей системе часто встречается ПОЛНЫЙ GC. Мы используем приложение Java, работающее на сервере Tomcat. Наше приложение работает с использованием внутренней настройки балансировщика нагрузки. Мы видим множество полных сборщиков мусора в журналах сервера, из-за которых приложение зависает и возникают ошибки прокси.
Мы используем следующие значения параметров Java: Оболочка Webapp: wrapper.java.additional.4 = -Xms382M wrapper.java.additional.5 = -Xmx1024M Оболочка Backapp: wrapper.java.additional.4 = -Xms382M wrapper.java.additional .5 = -Xmx1024M
Ошибка, обнаруженная в журналах оболочки веб-приложений: INFO | jvm 1 | 26.11.2010 09:33:19 | [PSYoungGen: 1398460K-> 140291K (1514624K)] 4623364K-> 3491394K (5009920K), 0,7285303 секунды] [Times: user = 1,42 sys = 0,00, real = 0,72 sec] ИНФОРМАЦИЯ | jvm 1 | 26.11.2010 09:33:19 | 68539.126: [Полная отладка GC | обертка | 26.11.2010 09:33:19 | отправить пакет PING: ping
Пытался изменить значения JVM, чтобы увеличить размер кучи. Но бесполезно. Я подозреваю, что может быть какая-то другая причина, помимо этих параметров, которая вызывает проблему.
Может ли кто-нибудь помочь мне в этом?
Добавьте этот параметр в свой setDomainEnv.sh: -XX: + DisableExplicitGC
Перезагрузите ваши серверы. Это позволит избежать каких-либо явных сборщиков мусора, которые могут быть вызваны приложением, и позволит JVM принять внутреннее решение и запустить полный сборщик мусора там, где это действительно необходимо.
Добавьте это в свой java_opts: "-XX: + UseConcMarkSweepGC" Это многопоточный сборщик мусора, который намного лучше работает при высокой нагрузке.
Полный сборщик мусора - важное событие в процессе сборки мусора. Во время этой фазы полной сборки мусора собирается мусор из всех регионов в куче JVM (Young, Old, Perm, Metaspace). Полный сборщик мусора имеет тенденцию вытеснять из памяти больше объектов, поскольку выполняется во всех поколениях. Событие Full GC состоит из нескольких фаз. Определенные фазы события Full GC (например, «initial-mark,« замечание »,« очистка », ...) приостанавливают все потоки приложения, на которых выполняется JVM. В течение этого периода транзакции клиентов обрабатываться не будут. JVM будет использовать все циклы ЦП для выполнения сборки мусора. Из-за этого загрузка процессора будет довольно высокой. Таким образом, в общем случае полные сборщики мусора нежелательны. Излишне спрашивать о желательности последовательных полных сборщиков мусора. Последовательные полные сборщики мусора вызовут следующие проблемы: