Настройка JVM (GC) для высокого быстро реагирующего серверного приложения
Я выполняю сервер приложений на Linux 64 бита с 8 базовыми центральными процессорами и 6 ГБ памяти.
Сервер должен быть очень быстро реагирующим.
После некоторого контроля я нашел, что приложение, работающее на сервере, создает скорее огромную сумму недолгих объектов и имеет долговечные объекты только на приблизительно 200~400 МБ (как долго, поскольку нет никакой утечки памяти),
После чтения http://java.sun.com/javase/technologies/hotspot/gc/gc_tuning_6.html я использую эти опции JVM
-server -Xms2g -Xmx2g -XX:MaxPermSize=256m -XX:NewRatio=1 -XX:+UseConcMarkSweepGC
Результат: незначительный GC берет 0,01 ~ 0,02 секунды, главный GC берет 1 ~ 3 секунды, незначительный GC постоянно происходит.
Как я могу далее улучшить или настроить JVM?
больший размер "кучи"? но потребуется больше времени для GC?
более крупный NewSize и MaxNewSize (для молодого поколения)?
другой коллектор? параллельный GC?
действительно ли это - хорошая идея позволить главному GC происходить чаще?еще как?
3 ответа
Результат: второстепенный сборщик мусора занимает 0,01 ~ 0,02 секунды, основной сборщик мусора - 1–3 секунды, второстепенный сборщик мусора происходит постоянно.
Если вы не сообщаете о паузах, я бы сказал, что сборщик CMS делает то, что вы его просили. По определению, CMS будет использовать больший процент ЦП, чем последовательный и параллельный сборщики. Это штраф, который вы платите за малое время паузы.
Если вы видите паузу от 1 до 3 секунд раз, я бы сказал, что вам нужно немного настроить. Я не эксперт, но похоже, что вам следует начать с уменьшения значения CMSInitiatingOccupancyFraction со значения по умолчанию 92.
Увеличение размера кучи улучшит «пропускную способность» GC. Но если ваша проблема - длинные паузы, увеличение размера кучи может усугубить проблему.
Возможно, вам будет интересно попробовать использовать сборщик мусора Garbage-First с низкой паузой вместо параллельной очистки меток (хотя он не обязательно более эффективен для всех коллекций, у него должен быть лучший худший случай). Он включен -XX: + UseG1GC и должен быть действительно классным соусом, но вы можете тщательно его оценить, прежде чем использовать в производственной среде. С тех пор он, вероятно, улучшился, но, похоже, год назад в нем были некоторые ошибки, как видно из Опыт работы с JDK 1.6.x G1 («Сначала мусор»)
Сборка мусора может выполняться параллельно с вашей программой, если у вас много ЦП, что вы и делаете.
Что вы хотите, так это убедиться, что вы не столкнетесь со сценарием, когда сборка мусора ПРИОСТАНОВЛЯЕТ вашу основную программу.
Вы пытались просто не указывать никаких флагов, кроме того, что вам нужна серверная виртуальная машина (для Sun JVM), а затем подвергать сервер большой нагрузке, чтобы посмотреть, как он себя ведет? Только тогда вы сможете увидеть, получите ли вы какие-либо улучшения от работы с опциями.