A
более того, часто при одной и той же нагрузке помогает уменьшение хмх, а не увеличение, опять же из-за эвристик гц
Size: a a a
2021 October 09
A
вообще плохая политика раздавать память просто чтоб гц дышало. зачастую стоит выяснить, что ее ест и с какой собссна целью, и убрать то на что ответ "хз"
VS
Точного правила нет, но есть обобщённая гипотеза GC: любому GC проще живётся, если у него есть память, в которой он дышит.
Если говорить про parallel GC, то у него типичная раскладка 66% old vs new.
Поэтому, если вдруг используется parallelGC, и реально занято (working set size) больше 66%, то каждая сборка мусора это будет full gc.
Если говорить про parallel GC, то у него типичная раскладка 66% old vs new.
Поэтому, если вдруг используется parallelGC, и реально занято (working set size) больше 66%, то каждая сборка мусора это будет full gc.
VS
Ещё ни разу отрицательного эффекта не видел, особенно, если не упираемся в общую нехватку памяти на машине.
Тут, конечно, стоит помнить про compressed oops, и что ставить Xmx в интервале 32ГБ…48ГБ смысла *вообще** нет.
Т.е. ставить нужно либо меньше 32Г, либо больше 48Г (см https://stackoverflow.com/a/13549938/1261287)
Тут, конечно, стоит помнить про compressed oops, и что ставить Xmx в интервале 32ГБ…48ГБ смысла *вообще** нет.
Т.е. ставить нужно либо меньше 32Г, либо больше 48Г (см https://stackoverflow.com/a/13549938/1261287)
VS
Недавний доклад Кирилла и Виктора удалось глянуть?
Они там говорили, что «замеры без мониторинга JMeter — время на ветер» (по-моему, я тоже говорил, но не суть 🙂 )
Так вот: конечно, стоит следить за «free heap after full gc» метрикой, и она как раз будет показывать «сколько используется памяти». И увеличивать-уменьшать нужно на её основе.
Они там говорили, что «замеры без мониторинга JMeter — время на ветер» (по-моему, я тоже говорил, но не суть 🙂 )
Так вот: конечно, стоит следить за «free heap after full gc» метрикой, и она как раз будет показывать «сколько используется памяти». И увеличивать-уменьшать нужно на её основе.
A
> Ещё ни разу отрицательного эффекта не видел
вот получали на бенчах (речь не про жметр): на хмх16 паузы дают всплески респонсов, на 20 история повторяется, уменьшаем до 12 — полетело. гц перестал делать долгие паузы
вот получали на бенчах (речь не про жметр): на хмх16 паузы дают всплески респонсов, на 20 история повторяется, уменьшаем до 12 — полетело. гц перестал делать долгие паузы
A
еще и пиво проспорила, тч помню крепко))
VS
Речь про G1? Про Java 1.8?
A
пока нет, не удалось. пока утверждение насчет мониторинга мне кажется сомнительным, опять же на высоких тпс. искусственно увеличить нагрузку. а если что-то пошло не так, то как понимать, что именно грохнулось? сокеты тоже
A
как доказать, что не мониторинг нагрузчика угробил тест
A
jmx весьма инвазивный
VS
GC log почти не влияет на скорость работы (можно сказать, вообще не влияет), если GC лог пишется на локальный диск, а не на сетевой
A
вы ж про "тесты без мониторинга нагрузчика — на ветер") гц логи и мониторинг — разное
A
я про мониторинг, когда какой-нить прометей метрики снимает
VS
Кому и гц лог мониторинг. Мы JMX с JMeter’а не снимаем. Ограничиваемся CPU/IO/GC
A
а че делаете с гц-логом? ну вот он есть, у него есть ротация (или вы без ротации?). какой кейс использования?
A
ротация == по мёрфи у тебя не будет лога за то время, которое интересно))
VS
Я же говорил, что у нас запускалка своя? Она и делает zip со всеми логами
Гц лог каждый раз с нуля начинается
Гц лог каждый раз с нуля начинается
A
окей, а как вы потом эти логи используете? когда \ как \ кем?
VS
Если возникает подозрение, то смотрим не зависал ли генератор нагрузки