Вертикальное масштабирование приложения Java реального времени

Question

С настройкой GC я успешно могу получить производительность для приложений Java в реальном времени и избежать распознаваемых пауз GC. Но это занимает до 20 Гбайт кучи.

Снижение стоимости оборудования сделало доступным даже 100 ГБ оперативной памяти. Но, все еще с Java из-за пауз GC, более высокие размеры кучи, такие как 50 ГБ, могут отправить вас в кошмар в обычное время.

Я понимаю, что есть варианты, такие как куча и распределенная куча. Но у кучи есть недостаток: se/derialization и распределенная куча на руке увеличивает стоимость обслуживания. Кроме того, в распределенной куче вы фактически не полностью используете ОЗУ (скажем, 64 ГБ), которые в наши дни становятся обычным явлением как товар.

Таким образом, чтобы полностью использовать потенциал ОЗУ, каковы хорошие решения для вертикального масштабирования приложений Java?

Answer 1

Я работаю над библиотекой примитивных коллекций под названием Banana. Банан обращается к тем точным вопросам. Вскоре он поддерживает LinkedLists, HashMaps и, возможно, другие структуры данных без накладных расходов на сохранение N объектов. в основном - все хранилище может находиться внутри массива int [] (или многих).

Хотя я еще не официально опубликовал его, большинство из них хорошо протестировано, и я уже успешно его запускал на серверах с 144 ГБ оперативной памяти, поддерживая быструю и стабильную работу без каких-либо пауз GC.

Отметьте this тест хэш-карты, чтобы получить представление о том, как использовать Банан для хранения данных и насколько он масштабируется по вертикали.

https://github.com/omry/banana/wiki/Long-to-fixed-size-object-benchmark

Смотрите wiki для получения дополнительной информации.

Answer 2

Время сбора мусора зависит от количества живых объектов в вашей куче. Это означает, что если ваш уровень распределения очень высок, но количество живых объектов всегда низкое, вы можете использовать столько оперативной памяти, сколько хотите, без значительных пауз.

Это утверждение особенно верно в отношении сборщика коллекторов (-XX:+UseParallelOldGC).

Если вы используете CMS, то вы, вероятно, захотите проверить его инкрементный режим (-XX:+CMSIncrementalMode). Это приведет к меньшему циклу CMS, чтобы очистить меньшую часть вашей кучи, одновременно используя ваше оборудование и без пауз STW.

Если CMS не является вариантом, тогда вы должны взглянуть на G1 (-XX:+UseG1GC), который представляет собой новый сборщик мусора, предназначенный для больших куч. Принцип: очистить только несколько областей кучи в каждом цикле, но убедитесь, что в этих регионах содержится много мертвых объектов (быстрая прибыль).

Надеюсь, что это поможет!

Источники:

• http://www.infoq.com/articles/G1-One-Garbage-Collector-To-Rule-Them-All
• http://jvm-options.tech.xebia.fr/

Answer 3

Я сделал некоторые исследования о масштабировании размер кучи JVM. Вы можете прочитать дополнительную информацию: here и here.

Основной вывод: молодая GC-пауза имеет две составляющие постоянной и переменной.

Постоянный компонент зависит от размера старого пространства и для 64GiB, я ожидаю, что он будет составлять 80 мс-120 мс (в зависимости от оборудования).

Переменный компонент зависит от выживания объектов в юном пространстве (таким образом, он изменяется от коллекции к коллекции). Это действительно специфическое приложение, но вы, как правило, можете уменьшить его, уменьшая молодое пространство (за счет более частых пауз).

В вашем случае для 4 GiB юного пространства у вас есть 500 мс. Предполагая переменную составляющую 400 мс, если вы уменьшите молодое пространство до 1 ГБ, у вас должно быть ~ 200 мсек пауз (но 2 раза в секунду).

Другим подходом является использование большего количества ядер процессора, молодого GC-параллельного соединения extremely well.

Answer 4

Сборщики мусора G1 и Shenandoah (экспериментальные) обеспечивают большую эластичность и разблокируют вертикальное масштабирование для приложений Java, оптимизируя использование памяти в соответствии с текущей нагрузкой. Другие особенности, как это работает, по крайней статье Minimize Java Memory Usage with the Right Garbage Collector