Содержание

понедельник, 4 апреля 2011 г.

GC tuning


Когда вы уже настроили все что только можно в вашем приложение, вы начинаете думать о тюнинге сборщика мусора. Бывает два пути оптимизации, которые ведут в две разные стороны: время пауз и общее время работы GC в процентом отношении к полезной работы приложения (throughput). Обычно всегда настраивают первое. Я приведу пример JVM параметров, на которых я остановился в своем приложении.
Довольно большой список JVM параметров можно посмотреть здесь и здесь. Хотя возможно он уже слегка устарел.

Подробное описание почему - читайте в моей статье на хабре.

10 комментариев:

  1. > Бывает два пути оптимизации
    Есть и третий, о котором вы написали в статье на хабре - поставить Azul VM, лучшего варианта оптимизации GC пока не придумали =)

    ОтветитьУдалить
  2. @Ilya - а вы сами пробовали Azul VM ?

    ОтветитьУдалить
  3. @Vladimir, да. Вдоль и поперек. Действительно хип в сотни гигабайт чистится без пауз. Могу попробовать ответить на конкретные вопросы.

    ОтветитьУдалить
  4. @Ilya наше общение с azul systems остановилось на том, что единственное решение, которое они могут предложить для коммерческого использования - это только через hypervisor, что в случае low latency application никак не годится.

    в какой конфигурации у вас работает ?

    ОтветитьУдалить
  5. @Vladimir, если честно, я вообще сам от туда. Могу предположить о чем речь.

    low latency application - это сколько секунд на транзакцию? Вы собирали логи GC, чтобы представлять о какую latency они вам приносят? особенно в пике.

    А чем использование гипервизоров плохо? В худшем случае добавится латенси от походов в сеть. Или low latency - это меньше миллисекунды? Network latency, обычно, гораздо меньше, чем GC latency.

    К слову о low latency - на решениях от Azul трейдинговые платформы работают. Куда уже больше (или меньше) low?

    P.S.: вы не в Авроре случайно? можно во дворе на солнышке пообщаться =)

    ОтветитьУдалить
  6. Итог беседы Владимира и Ильи(представитель azul systems): на данный момент существующее решения от Azul на стандартном железе через виртуалку на гипервизоре имеет смысл использовать только в случае хипа, начиная от нескольких гигабайт. Если же у вас хип порядка гига или еще меньше, то скорее всего вы стандартный HotSpot GC сможете настроить с меньшими паузами. Т.е. если ваш таргет порядка 10 миллисекунд, то Azul пока что не вариант. Ждем решения от Azul без виртаулки и гипервизора на стандартном железе!

    ОтветитьУдалить
  7. Я бы сказал, что прямым показанием к использованию являются проблемы с GC. Не важно каков размер хипа. Начиная от -Xmx2g паузы просто очевидны.

    И вот это
    "HotSpot GC сможете настроить с меньшими паузами"
    невозможно.

    ОтветитьУдалить
  8. Свершилось то, чего мы все так долго ждали: Azul выпустил нативное решение на линуксе без виртуализации. Она уже прошла бета тестирование и теперь у них уже GA релиз. Пока что поддерживаемый список систем ограничен Red Hat Linux 6, and CentOS 6, но они работают над расширением.
    http://www.infoq.com/news/2011/11/zing5-native

    ОтветитьУдалить
  9. Артём, поделитесь готовым списком параметров с использованием G1 сборщика.

    Подскажите параметры для однопоточного realtime серверного приложения.

    Железо: i7 4ядра, HT, память 16GB
    Активно используется только 1 ядро. С настройками GC по умолчанию, приложение забивает всю xmx память за 40 минут. 90% данных в массивах байт. 5% в массивах Object.

    С такими настройками работает специфично:
    производительность (кол-во тиков главного цикла в секунду) скачет в пределах 1/4..1/2 от идеальной (без нагрузки).
    За первые час работы происходит несколько тяжелых сборок (раз в 30-40 минут), которые приводят к некритическим ошибкам (данные не портятся) и часть пользователей теряет соединение.

    Через 2 часа постоянной нагрузки, использование памяти останавливается на отметке 2Gb, процессор используется на 15%. Производительность сервера держится на отметке 1/2. Что тоже неплохо.
    Oracle jre 1.7u2

    java -server -Xms1G -Xmx7G -XX:PermSize=256m -XX:MaxPermSize=256m -XX:+DisableExplicitGC -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:+UseNUMA -XX:+CMSParallelRemarkEnabled -XX:MaxGCPauseMillis=50 -XX:+UseAdaptiveGCBoundary -XX:-UseGCOverheadLimit -XX:+UseBiasedLocking -XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=90 -XX:MaxTenuringThreshold=15 -XX:UseSSE=3 -XX:+UseLargePages -XX:+UseFastAccessorMethods -XX:+UseStringCache -XX:+UseCompressedStrings -XX:+UseCompressedOops -XX:+OptimizeStringConcat -XX:+AggressiveOpts -jar my.jar

    К сожалению, у меня нет фундаментальных знаний о работе GC и КПД моего анализа логов GC близок к нулю. За сим прошу помочь с выбором параметров.

    С благодарностью.

    ОтветитьУдалить
  10. Илья, если можно,хотелось бы войти с вами в контакт, обсудить некоторые вопрос об Azul VM ;) Мое контактны данные в моем профиле.

    Спасибо,
    Михаил

    ОтветитьУдалить