Низкая пропускная способность обслуживания из-за частого сбора мусора

Question

У меня есть служба, работающая в системе с 16 ГБ ОЗУ со следующими конфигурациями:

-Xms6144M"
-Xmx6144M
-XX:+UseG1GC
-XX:NewSize=1500M
-XX:NewSize=1800M
-XX:MaxNewSize=2100M
-XX:NewRatio=2
-XX:SurvivorRatio=12
-XX:MaxGCPauseMillis=100
-XX:MaxGCPauseMillis=1000
-XX:GCTimeRatio=9
-XX:-UseAdaptiveSizePolicy
-XX:+PrintAdaptiveSizePolicy

В нем работает около 20 опрошенных, каждый из которых имеет ThreadPoolExecutor размера 30 для обработки сообщений. Первоначально в течение 5-6 часов он мог обрабатывать около 130 сообщений в секунду. После этого он мог обрабатывать только около 40 сообщений в секунду.

Я проанализировал журналы GC и выяснил, что Full GC стал очень частым, и более 1000 МБ данных передавалось из Young в Old Generation:

Глядя на дамп кучи, я вижу множество потоков в состоянии ожидания, подобных этому: WAITING at sun.misc.Unsafe.park (собственный метод) И объекты следующих классов, приобретающие наиболее сохраняемый размер:

Я думаю, что может быть небольшая утечка памяти в службе и связанных с ней библиотеках, которая накапливается со временем, поэтому увеличение размера кучи только откладывает это. Или, может быть, из-за того, что Full GC стали очень частыми, все остальные потоки очень часто останавливаются (паузы "останови мир"). Нужна помощь, чтобы выяснить причину этого поведения.

Answer 1

Шаблон GC выглядит как утечка памяти.

Глядя на вашу статистику дампа кучи, я вижу задачи 3M, ожидающие выполнения в пулах потоков.

Могу предположить, что вы используете пулы потоков с неограниченной очередью задач.Ваша входящая скорость передачи сообщений больше, чем вычислительная мощность системы, поэтому отставание растет, потребляя больше памяти, что в конечном итоге приводит к смерти GC.

В зависимости от вашего случая, вы можете либо ограничить размер очереди для пула потоков, либо попробоватьоптимизировать объем памяти задач очереди.

Ограничение размера очереди создаст обратное давление на предыдущем этапе обработки.Если это простой таймер, управляемый таймером, который является производителем для пула потоков, то эффект будет уменьшать интервал опроса (так как он будет блокировать ожидание места в очереди).

Оптимизация занимаемой памяти задач будет работать только при ваших возможностях обработкив среднем больше, чем частота входящих задач, и проблема вызвана временным всплеском.