Comments 21
Спасибо за интересную статью.
Можете немного пояснить:
1. какая версия jvm использовалась?
2. почему проверяли только эти 2 сборщика мусора?
3. почему не использовали другие параметры для сравнения? Например, CMSInitiatingOccupancyFraction.
Можете немного пояснить:
1. какая версия jvm использовалась?
2. почему проверяли только эти 2 сборщика мусора?
3. почему не использовали другие параметры для сравнения? Например, CMSInitiatingOccupancyFraction.
Спасибо за отзыв.
1. java version «1.8.0_66»
Java(TM) SE Runtime Environment (build 1.8.0_66-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.66-b17, mixed mode)
2. Они широкодоступны и бесплатны.
3. Использовали некоторые. В статью попали только те, которые оказали заметный эффект на результат.
1. java version «1.8.0_66»
Java(TM) SE Runtime Environment (build 1.8.0_66-b17)
Java HotSpot(TM) 64-Bit Server VM (build 25.66-b17, mixed mode)
2. Они широкодоступны и бесплатны.
3. Использовали некоторые. В статью попали только те, которые оказали заметный эффект на результат.
Попробуйте JDK 9 EA. Шипилев говорит туда вошло дочерта вссего для G1, что не вошло в 8u
Надеюсь, в 9 не будет такой проблемы с G1: habrahabr.ru/company/jugru/blog/280420/#comment_8831960
Я имел в виду встроенные, например, UseParallelOldGC.
А можете написать, какие параметры ещё пробовали, т.е. что не повлияло на результат.
Например, CMSScavengeBeforeRemark или что-то подобное.
А можете написать, какие параметры ещё пробовали, т.е. что не повлияло на результат.
Например, CMSScavengeBeforeRemark или что-то подобное.
В девятке должны поправить проблему со String Deduplication:
https://bugs.openjdk.java.net/browse/JDK-8158871
Я правильно понял из таблицы, что при хипе в 12GB максимальный размер паузы для CMS-5 составил 3 секунды? При том, что promotion failure и concurrent mode failure не было? Тогда это очень странно. У нас на сервере, обрабатывающем 15000 rps, с 54GB хипом максимальная пауза за 500 мс не выходит. Что логи говорят, на какую фазу больше всего времени уходит?
также интересно, использовалиcь ли какие-то ключи специфичные для CMS? Из статьи только видно что указывался NewRatio
Пауза 3 сек за 16 часов была только одна. Без failures. Возможно, сыграл роль какой-то внешний фактор.
Распределение времени по фазам можно увидеть на графиках.
Для корректности сравнения укажу модель процессора на этом сервере: Intel® Xeon® CPU E3-1246 v3 @ 3.50GHz
Распределение времени по фазам можно увидеть на графиках.
Для корректности сравнения укажу модель процессора на этом сервере: Intel® Xeon® CPU E3-1246 v3 @ 3.50GHz
А, судя по графику, это сборка в ParNew. И там ещё несколько точек около 1 секунды. Для сборки в молодом поколении (размер которого 2GB) это тем более много.
Такое бывает по разным причинам: либо чрезмерное количество Weak/Soft-ссылок, либо множество ссылок из старого поколения в новое, либо сильная фрагментация старого поколения, либо ресайз хипа, если его размеры не фиксированы, либо дисковая активность, попавшая на период сборки… В общем, я к тому, что делать выводы об эффективности GC без должного анализа — преждевременно. Точно так же, как и по результатам бенчмарка судить о производительности приложения.
Такое бывает по разным причинам: либо чрезмерное количество Weak/Soft-ссылок, либо множество ссылок из старого поколения в новое, либо сильная фрагментация старого поколения, либо ресайз хипа, если его размеры не фиксированы, либо дисковая активность, попавшая на период сборки… В общем, я к тому, что делать выводы об эффективности GC без должного анализа — преждевременно. Точно так же, как и по результатам бенчмарка судить о производительности приложения.
Просто инетресно а Azul не пробовали? https://www.azul.com/products/zing/pgc/
1) действительно, почему не azul
2) почему java? (на самом слабом инстансе digitalocean «серверок» на golang показал рекорд в 9 микросекунд на разумный ответ)
2) почему java? (на самом слабом инстансе digitalocean «серверок» на golang показал рекорд в 9 микросекунд на разумный ответ)
А нельзя ли как-то вручную управлять сборкой мусора и принимать запросы на другой инстанс, пока один собирает мусор?
«При таких показателях на один Full GC в течение 16 часов можно закрыть глаза»
Вы ж так не пугайте. Уже из каментов я понял, что речь о FullGC который выполняется 3сек. А читая статью, я решил что у вас GC реально 16 часов работал. Долго думал как же это можно так загадить 4.5гига, чтобы они так долго чистились, и что ж это за такая задача, в которой можно простить 16часов сборки мусора.
Вы ж так не пугайте. Уже из каментов я понял, что речь о FullGC который выполняется 3сек. А читая статью, я решил что у вас GC реально 16 часов работал. Долго думал как же это можно так загадить 4.5гига, чтобы они так долго чистились, и что ж это за такая задача, в которой можно простить 16часов сборки мусора.
Сталкивались ли вы при работе «UseConcMarkSweepGC» и «UseParNewGC» с логами вида 'GC (Allocation Failure)'? Если да, то как их решали?
2015-06-09T12:37:01.670+0300: [GC (Allocation Failure) 2015-06-09T12:37:01.670+0300: [ParNew: 77111K->4149K(78656K), 0.0092402 secs] 161272K->88309K(253440K), 0.0094265 secs] [Times: user=0.02 sys=0.00, real=0.01 secs]
2015-06-09T12:37:01.670+0300: [GC (Allocation Failure) 2015-06-09T12:37:01.670+0300: [ParNew: 77111K->4149K(78656K), 0.0092402 secs] 161272K->88309K(253440K), 0.0094265 secs] [Times: user=0.02 sys=0.00, real=0.01 secs]
Очень интересно, насколько зависят ваши результаты от самого приложения, у нас, например, Eden заполняется очень быстро, при этом OldGen растет медленно, поэтому NewRatio мы ставим 1.
Подскажите, каким инструментом пользовались для построения графиков и сводных табличек по логам GC?
Sign up to leave a comment.
Выбор и настройка Garbage Collector для Highload системы в Hotspot JVM