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

Для начала — точная версия и производитель 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 как полагается.

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

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

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

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

@fidel_alejandro_castro_ruz

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

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

https://youtu.be/ulWWSKr0Ce0, https://youtu.be/r_bnfv-nlcs, https://youtu.be/iB2N8aqwtxc

Англоязычные: https://youtu.be/CZytwF_y_x8, https://youtu.be/LJC_2agoLuE

Ну и https://shipilev.net/, конечно.

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

• http://www.oracle.com/technetwork/java/javaseproducts/mission-control/java-mi...
• http://www.oracle.com/webfolder/technetwork/tutorials/obe/java/mc-jfr/index.html
• https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/tooldescr...
• https://docs.oracle.com/javacomponents/jmc-5-4/jfr-runtime-guide/run.htm

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

наоборот, нужно уменьшать -Xmx чтобы цикл Full GC занимал меньше времени.

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

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

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.

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

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

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

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

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

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

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

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

Вот у неё спроси:

https://getfedora.org/uk/workstation/

Она лучше всех знает, как посадить JVM на диету.

uk

Открыл, а там все по украински...

Не то uk шо я ожидал XD

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

Погляди на сайте датастакса, у них был описан процесс тюнинга под кассандру.

Наверное стоит смотреть тогда сюда: https://www.azul.com/products/zing/virtual-machine/

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

к нему в крайнем случае. он платный (я ошибаюсь?)

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 чуть менее, чем нифига.

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

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

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.»

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

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

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

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

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

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

RTFM

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