Максимум который можно дать JVM на практике - 31Gb, дальше наступает сильная деградация. В остальном все зависит от приложения, на большом объеме памяти большие паузы GC.

Ну конечно же каждый сервис в отдельный контейнер с zulu от azul. И не забыть каждый контейнер ограничить, мы же хипсторы. А для тормозов нужно иметь задачи соответственные, так что исходим из того, то что проще управлять, и то что из-за одной кривой программы, в случае использования одной jvm все не ляжет. А так думается, что в особенно отсталых случаях, azul тебе просто предложит купить машину под твои задачи.
И да не забывай, что есть еще jvm и без jit, например Excelsior JET, которой прогрев не нужен, но нужно компилять. Idea c JET кстати быстрей работает, хотя тем кто idea не отключает, конечно это будет врядли заметно.

так поставь Azul Zing и потестируй.

Какой JVM? Ты сразу уточняй, ага. Azul может ворочать терабайтным хипом и не кашлять.

а ты пробовал увеличивать дальше? помойму как раз на промежутке с 31 до 60 есть запланированная деградация. Ну и гц должен быть G1 или Shenandoah. Тут основной выбор между тем, как бы сделать чтобы в G1 не случился full gc (который на терабайте памяти займет ~10 минут), и Shenandoah который пока в бетке (и в нем могут всплыть неизвестные страшные баги). Ну и Азул, который «платный».

UPD: За 31 гиг спасибо, буду оперировать этой цифрой. Это какой GC?

Если запилить все сервисы в одну жвм то очевидно при факапе они помрут все сразу. Это основной недостаток конструкции. А по поводу потребеления памяти - это надо смотреть как каждый конкретный сервис гадит в память и насколько тяжело приходится гц с тем что там валяется. Тут либо к телепатам либо в джоб.

В таком ключе всё просто:

если юзать CMS GC то 4Gb это рекомендуемый потолок для хипа

если очень нужно >4Gb то тут только G1 (ну или коммерческие jvm про кторые я не скажу больше чем ихние маркетологи)

+ в сторону CMS и 4Gb jvm'ах в том что каждый инстанс можно подтюнить отдельно, под характеристики утилизации памяти, да и модель памяти у него попроще

- микро-vm в том что если у тебя 10 инстансов которое раз в неделю жрут все 4 Гб, то будут заняты все 40Гб выделенные, в G1 же есть вероятность что они жрат память будут не одновременно, но это всё вероятности: может повезет, а может нет. В любом случае jvm не вернет память системе.

Про 40gb хипа, вот представь себе что у тебя при стандартных 1/3 хипа под young gen, у тебя выделяется 13Gb под eden:

А это значит что JVM будет бездумно набивать 13Gb памяти ничего не удаляя, а потом, попытается её чистить. Да, G1 интересно сделан и разбитие на регионы избавляет от радости одним махом удалять 13Gb, но всёравно, чем меньше тредов в инстансе, тем быстрее делать mark phase т.к. корней GC меньше.

Т.ч., ИМХО, большие хипы нуждны только в 1 случае, когда у нас есть огромный, немасштабируемый легаси проект с синхронизацией при помощи synchronized(hash-map) который может работать только в одном инстансе

С джетом проблема в том, что Пашин телефон я потерял вместе с телефоном, а кто еще из живых людей видел этот CoreBalance - неизвестно.

И вообще с джетом та же проблема, что и с Азулом - они ПЛАТНЫЕ. Не в формате платной техподдержки, а именно сам продукт платный. Заапрувить использование такого продукта в качестве основы для собственной платформы - бесконечно тяжко.

Я даже не знаю, что за CoreBalance. Но JET можно попробовать бесплатно и получить бесплатно для open-source или дже для некоторых free продуктов.
Другое дело что для большинства задач хватит сборок openjdk, я уже упомянул zulu кажется.
И да вообще как мне показалось большинство клиентов JET, используют даже не из-за производительности, а просто чтобы сорцы было сложней достать, или получить что-то более-менее читабельное со всякой проприетарщины.

Наймите специалиста. Видно же, что вы просто тратите деньги компании при этом сами в предмете вопроса совершенно не разбираетесь.

А ты забавный.

Ты просто дурной. Вместо того, чтобы спрашивать на лоре, ты бы уже давно запустил свое поделие и посмотрел через какой-нибудь профайлер на GC pauses и allocation rate и memory footprint. Вместо этого, ты тут рассусоливаешь про Azul Zing и JET на которые тебе все равно не дадут денег.

Где-то читал умную статью(кто-то замерял), итогом которой был сделан вывод что реально 2-3GiB оптимальная порция кучи, и советуют если есть возможно то лучше разбить сервер на десяток мелких жвм(даже на одном хосте), чем один большой. Виновником такого парадокса назвали GC который просто зашивается на больших объемах.
(да, и хип-дамп 3 ГиБ проще переваривать чем 16ГиБ).

Я выставляю обычно Xmx 16GB. (Джентельменский набор кодера - Spring, Hibernate, GWT).

К сожалению, более 31GB пока не пробовал.

Если Вы накидаете мне ссылок почитать про память более 31 GB и поведение JVM - я буду весьма признателен.

Причина - у заказчиков скоро появятся компы с памятью под 32..64 GB.

31 Gb это порог на котором заканчивается compressed oops. Но в целом на 30Gb надо G1, дефолтный хуже себя ведёт.

Я обычно выставляю -Xmx192m, а потом увеличиваю этот лимит когда появляются основания это сделать. Чего там можно в 16Gb засунуть в таком приложении? Кеш?

Да, кэш.

Обычно ставлю java -Xms1G -Xmx16G.

Приложения очень «нагруженные».

Из более или менее полезной инфы используем

http://blog.sokolenko.me/2014/11/javavm-options-production.html

и

http://www.oracle.com/technetwork/tutorials/tutorials-1876574.html

Это как шахматы - искусство, а не наука.

бери кресты и не парься

там никаких магических чисел нет. используй сколько надо.

текущее состояние:

аргументы против:
- если на G1 случится full gc, то это 10 минут
- если на CMS будут случаться concurrent mode failure, то это тоже плохо (нет замеров)
- Азул стоит денег и закрыт
- Shenandoah в бете и может содержать неизвестные критические ошибки
- Для Shenandoah нужно самостоятельно собирать JVM, что осложняет приемо-сдаточные испытания и выкатку на прод (продовикам придется объяснять, что мы используем кастомную джаву, потому что экспериментальный коллепктор, и после этого доказывать необходимость этого коллектора). Завтра с утра сделаю билд, да.
- Деградация 30-40 Гб из-за compressed oops (но мы эти гигабайты сразу пролетим и будем ставить не меньше 64, так что это надуманная проблема)
- если сломается одно из приложений (начнет течь память или что-то такое), то с высокой вероятностью на Java7 придется перегружать всю JVM, и никакой аппликейшен сервер не поможет

аргументы за:
- высокая энергоэффективность
- легкость девопса в случае отсутствия ошибок (можно делать весь девопс с помощью кода на джаве, даже не делая для этого каких-то специальных утилит. Тот же OSGi и поехали)
- легкость выкладывания на прод (выкладывается одна машина со всем-всем, соответственно документацию можно готовить не на 100500 проектов, а только на 1, то же про официальный «процесс развертывания»)

Азул стоит денег и закрыт

Алгоритм работы их GC описан в статье — реализуй не хочу!

Шенандоа не готова к прод использованию. Но судя по мейллисту ее теперь активно пилит А. Шипилев, так что можно ожидать хороших результатов в будущем.

Юзай много маленьких (до 10gb) хипов.

Фулл ЖЦ в Г1 - это failure state, на приложениях заботящихся о расходе памяти (в реальности таких мало разумеется) случаться вообще не должен.

Если есть возможность - юзай оффхип по максимуму (ограничения на память от ЖЦ все, выделение памяти дешевое и 100гб в оффхипе - на ура работает).

Про платность зинга/жета улыбнуло, а оракложаба бесплатная наверное да, сколько тогда интересно стоит запустить Флайт Рекордер на продакшен сервере? И где бы бесплатно взять jdk7 с последними патчами безопасности?

Ее Шипилев мне и рекомендовал использовать, так что всё-таки относительно готова

всё-таки относительно готова

Теги: «безумство храбрых», «пение песен».

Готовься, что тебя DevOps'ы c говном сожрут за использование оных в качестве бета-тестеров. Но стремление похвальное, да.

Напиши тогда как пройдет, интересно.

Тот же вопрос обсуждают: https://groups.google.com/forum/#!topic/mechanical-sympathy/-XHui4n6bYk

можно делать весь девопс с помощью кода на джаве

Что ж за беда-то такая...

Не надо в один артефакт запихивать приложение и окружение. Приложение должно быть одним immutable-артефактом, который знать не знает в каком окружении он запущен и чем отличается prod от dev или от stage.

Иначе фольксвагеновское if jenkins then exit 0 еще цветочками окажется.

Максимум который можно дать JVM на практике - 31Gb

То-то твиттер своим поисковым JVM выделяет по 64 Гб (google://Earlybird).

Early bird это ж специализированное хранилище, которое оптимизировали для достижения высокой производительности, и в статье описано как они его оптимизировали для снижения количества мусора в процессе работы. Он работает не так, как типичные энтерпрайзные опердени.

И потом вся информация об этом довольно старая, может они уже поменяли конфигурацию.