LINUX.ORG.RU

JVM Tuning

 , ,


5

3

Есть тут кто-нибудь, кто умеет крутить ручки JVM'у?

дано: кассандра, которая после разрастания кейспейса > 200Гб начинает люто тормозить.

нужно: сделать счастье.

небольшой разбор полетов привел к GC. хочется понять, как лучше накрутить JVM, чтобы не залипало на 10 секунд по нужде GC.

тут небольшой лог с метриками и параметрами

http://gceasy.io/my-gc-report.jsp?p=c2hhcmVkLzIwMTcvMTIvNS8tLWdjLmxvZy4wLmN1c...

Deleted

DELETED. Не посмотрел флажки.

Deleted ()
Последнее исправление: Deleted (всего исправлений: 1)

Для начала — точная версия и производитель JVM. Потому как Oracle JDK и OpenJDK (включая сборки Azul Zulu) различаются слегка, а J9 от них обоих отличается радикально.

Далее, почитай о видах GC (Serial, Parallel, CMS, G1) и реши, что тебе важнее — throughput (квант работы в единицу времени) или latency (отзывчивость).

После этого ищешь в сети по сочетанию «JVM performance tuning» (есть уйма статей на oracle.com, например, и habrahabr.ru, например). Есть также уважаемые люди по имени Алексей Шипилёв, Руслан Черёмин и/или Глеб Смирнов. Находишь их доклады с конференций JPoint и Joker на YouTube, слушаешь и просветляешься.

Затем с багажом полученных знаний присасываешься к целевой JVM по протоколу JMX утилитой jmc.exe, опционально включаешь Flight Recorder, и настраиваешь GC как полагается.

Вот, как-то так...

Bass ★★★★★ ()

P.S. У тебя львиную долю времени занимает Full GC. Если нужно именно повысить отзывчивость («люто тормозить» — это слишком широкое и некорректное в данном случае понятие), то смотришь в сторону CMS или G1, а также в сторону увеличения heap limit (-Xmx).

Bass ★★★★★ ()
Ответ на: комментарий от Bass

я уже переключался на G1 с увеличением кучи до 24Гб. не спасло :(. у меня, конечно, нет опыта тюнинга jvm, да и в целом я не джавист, просто эксплуатация кассандры привела к попытке погрузиться.

PS: могу я тебя поспрашивать в каком-нибудь телеграме? оч выручишь

Deleted ()
Ответ на: комментарий от Deleted

@fidel_alejandro_castro_ruz

Но у меня время реакции исчисляется днями — дети.

Реально рекомендую послушать доклады о GC — хотя бы Шипилёва. Он сейчас ушёл из Oracle в RH и они пилят Shenandoah.

Bass ★★★★★ ()
Ответ на: комментарий от Deleted

Про Flight Recorder (имеет смысл, если у тебя Oracle JDK):

Просто Java Mission Control — это едва ли не единственный из бесплатно доступных инструментов, способных предоставить тебе вменяемую аналитику. Ещё есть VisualVM, но он убог.

Bass ★★★★★ ()
Ответ на: комментарий от dzidzitop

Я дочь офицера, не всё так однозначно.

Ты ни разу не ловил

java.lang.OutOfMemoryError: GC overhead limit exceeded

потому что поток, в котором работает GC, занимает ~99% CPU time per core, и в результате JVM не выполняет полезной работы, кроме сборки мусора?

Теоретически да, возможно, но время сборки мусора пропорционально объёму объектов в Eden Space, а это не обязательно то же самое, что и размер кучи.

Кроме того, в первую очередь (хотя зависит от задачи, конечно) напрягают не паузы GC, а так называемые события типа «остановись, мгновение» (stop the world event). Когда «залипает на 10 секунд» — это именно stop the world.

Bass ★★★★★ ()
Последнее исправление: Bass (всего исправлений: 2)
Ответ на: комментарий от Bass

Видел конечно. Как видел и затупы GC на перебирании лишних гигабайт мусора.

Поэтому меньший хип может дать лучший full GC latency. Но если переборщить, то можно и получить то, что ты процитировал. В любом случае, на хипах в десятки гигабайт (нафига такие вообще?) стоит пробовать.

Как и стоит пробовать вынести все эти гигабайты за пределы хипа.

dzidzitop ★★ ()

Да и вообще - стоит осознать одну простую вещь: процессор может обработать несколько десятков гигабайт памяти за секунду при самых комфортных для себя условиях (условия для вызова memset).

GC - это чаще всего random access, с переключениями банков памяти, неработающим prefetch, бранч миспредиктами, NUMA, переключениями страниц виртуальной памяти и прочей хренью.

Поэтому наивно ожидать, что full GC хипа на 20 GiB будет занимать секунду. Можно только пробовать использовать либо параллельную сборку мусора или (относительно) неблокирующую или не использовать хипы таких дурных (относительно современного железа) объёмов.

dzidzitop ★★ ()
Последнее исправление: dzidzitop (всего исправлений: 1)
Ответ на: комментарий от dzidzitop

Вот, пожалуй, соглашусь.

Но основное — это таки пробовать. В рамках конкретной задачи.

Bass ★★★★★ ()
Ответ на: комментарий от Bass

Спасибо огромное за такую подборку ссылок! много полезной информации

Deleted ()
Ответ на: комментарий от ya-betmen

по иронии, после прочтения их мануалов пришел сюда )

Deleted ()
Ответ на: комментарий от Deleted

Azul Zing — это JVM с pauseless GC (их реализация называется c4, по ссылке его сравнение с G1 и аналогами). На самом деле, из ныне существующих продуктов конкуренцию ему составит разве что Shenandoah (но он пока не готов для боевого использования), ну и у IBM ещё что-то было своё (чуть ли не в J9). Вся эта затея про pauseless GC нужна для реализации т. наз. «soft realtime» на Java.

В твоём случае — это по воробьям из пушки. Нужно либо настраивать GC, либо пересматривать архитектуру (т. е. фактически сценарий использования Cassandra).

Я бы сделал следующее:

  • Посидел бы с JMC/VisialVM/любым профайлером типа YourKit (есть тестовая версия на 2 недели)/Plumbr (если твоя JVM имеет выход наружу и может слить телеметрию) и попробовал таки настроить GC. В случае с Plumbr, если собранная статистика для тебя лично будет неинформативна, добрые дяди из той же компании за разумные деньги всё настроят сами.
  • Если п.1 не помогает, то перевёл бы вопрос на буржуйский и задал бы на StackOverflow.com, с указанием примерной архитектуры и характерного объёма обрабатываемых данных. Потому как здесь экспертов по настройке JVM чуть менее, чем нифига.
Bass ★★★★★ ()
Ответ на: комментарий от Bass

Просто Java Mission Control — это едва ли не единственный из бесплатно доступных инструментов,

4.2 (точнее скоро откроют и не будет 4.2, но пока 4.2). JMC бесплатный только вне продакшена, а на продакшене он не только платный, но еще и оче дорогой (помню в HFT-шники охреневали от его стоимости), так как разрешен для использования в проде, только если есть контракт с ораклом на поддержку всей жабы.

anonymous ()

RTFM

Для начала выбросить весь тот бред, что написан в command line flags, проапдейтить JVM до максимально возможного в текущей обстановке и дальше смотреть по обстоятельствам.

В логе видно CMS Full GC ввиду Concurrent Mode Failure. Это означает, что concurrent mark-sweep в CMS не успел прибраться в куче, до того, как память кончилась. В CMS Full GC однониточный. Немудрено, что он 10 секунд занимает. Отсюда два выхода: а) посмотреть на аппликуху и докрутить CMS до того, чтобы он не валился в Concurrent Mode Failure (стартовать цикл пораньше, и т.п.); б) переехать на G1, который должен быть более устойчив к подобному (хотя Full GC там тоже однониточный).

Да даже если репорт внимательно читать, там есть:

«Solution: The concurrent mode failure can either be avoided by increasing the tenured generation size or initiating the CMS collection at a lesser heap occupancy by setting CMSInitiatingOccupancyFraction to a lower value and setting UseCMSInitiatingOccupancyOnly to true. CMSInitiatingOccupancyFraction should be chosen carefuly, setting it to a low value will result in too frequent CMS collections.»

anonymous ()
Ответ на: RTFM от anonymous

Спасибо за дельный совет.

Для начала выбросить весь тот бред, что написан в command line flags

там большинство параметров - дефолтные кассандровские. мне тяжело разбирать их на «бред» и «не бред», поскольку я в java-мире совсем ничего не понимаю :)

проапдейтить JVM до максимально возможного в текущей обстановке и дальше смотреть по обстоятельствам.

текущая обстановка - Debian 9 и JVM, которая там идет дефолтом.

На G1 уже пытался переключаться. Не помогло. Лог, что тут привел уже не первая итерация в попытках покрутить параметры. А если учесть мой нулевой опыт в JVM, то появление здесь топика с вопросом вполне закономерно.

RTFM

у меня не было планов стать гуру приготовления JVM. в конце-концов я не девопс и не java-девелопер. если уж столько проблем и количества рычажков у JVM, то есть шанс, что уйдем от кассандры в сторону drop in replacement - scylladb (та же кассандра, только написанная на C++, не требующая владения «кунг-фу» в области JVM)

Deleted ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.