Как выбрать размер кучи JVM?

Question

Что я обычно делаю в отношении размера кучи jvm, так это устанавливаю максимальное значение max, чтобы избежать печально известного исключения OutOfMemoryException.

Однако эта стратегия (или ее отсутствие) не кажется действительно умной. : -).

Мой вопрос заключается в том, как выбрать минимальное и максимальное значения и разницу между этими двумя значениями (максимальное или минимальное значение должно быть большим или меньшим?). Например, с здесь :

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

спасибо.

Answer 1

У меня вопрос как выбрать мин и максимальные значения, и разница между двумя (должно быть макс-мин маленький или большой?)

Краткий ответ: не угадайте, профилируйте вашу заявку.

jconsole может предоставить вам полезные высокоуровневые данные , например, ощущение основного резидентного набора в сравнении с переходными данными, которые мы обычно выделяем и собираем мусор. То, что вы увидите, если вы посмотрите на вкладку памяти этого дисплея, обычно выглядит как пилообразный. Нижний угол пилы - это то место, где я обычно устанавливаю минимум кучи, тогда как я использую пик или наклон пил, чтобы экспериментировать с максимумом кучи. Если ваши зубы очень крутые, вы можете подумать о большой куче, просто чтобы отложить сборку мусора. Однако, если это не так, вы можете попробовать меньший максимум кучи, чтобы посмотреть, не оставит ли это больше ресурсов для других процессов на вашей машине (например).

Также следует учитывать серверную виртуальную машину , так как это приведет к другому поведению при сборке мусора.

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

Answer 2

Вы должны включить ведение журнала GC и проверить, где происходит OOM.

-verbose:gc
-Xloggc:gc.log  
-XX:+PrintGCTimeStamps
-XX:+PrintGCDetails

Возможно, вы испытываете ограничения по пермскому пространству, отрегулируйте с помощью -XX:MaxPermSize=YYYm

В любом случае, чтобы ответить на ваш вопрос, я начинаю с минимумов и устанавливаю максимум относительно высоким. Затем я строю график журнала gc и выясняю, где находится мое состояние; визуально выберите размер выше среднего для разных поколений. Прочитайте его, как финансовую диаграмму, вы захотите увидеть хороший разброс в новых поколениях и последовательный рост и сбор в постоянном поколении. Как уже упоминалось, также нанесите на график ваше пространство для перми, чтобы убедиться, что вы не постоянно увеличиваете.

GC-тюнинг - это искусство, никак не наука.

Answer 3

Действительно, установка максимального максимального значения вслепую - не очень хорошая идея (измерить, не угадывать), и эта стратегия приведет к очень долгому «остановлению мира» основных ГК, что может быть нежелательно с точки зрения пользовательского опыта. зрения (всегда помните, что «чем больше куча, тем длиннее основной сборщик мусора»).

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

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

Answer 4

Это очень плохая идея - "игнорировать параметр -Xms", так как обычно на этом же компьютере выполняются другие приложения и процессы. Вы хотите, чтобы ваше приложение запускалось с максимальным объемом выделенной оперативной памяти, поэтому, если оно завершится сбоем, оно завершится сбоем во время просмотра журналов запуска, а не в 4:00, когда другое приложение заняло дополнительную оперативную память на коробке, и ваша JVM не может увеличиться в размере.

Короче говоря, ВСЕГДА устанавливайте минимальную JVM и смешивайте размер с одинаковым значением.

Answer 5

Если вы испытываете OOME, я бы начал с увеличения максимальной памяти, насколько это возможно, и посмотрел бы, решит ли это проблему. Позвольте вашей машине в первую очередь решить проблему с производительностью. Если проблема не устраняется, вы можете обратиться к диагностике производительности, чтобы выявить узкие места и поработать в тех областях, где ваше приложение может протекать или может занимать больше всего памяти.

У Джеффа Этвуда есть хорошая статья о CodingHorror, которая объясняет это отношение; наиболее экономически эффективное решение проблемы с производительностью заключается в том, чтобы бросить аппаратное обеспечение (или в этом случае увеличение ресурсов памяти) на решение проблемы, прежде чем тратить время разработчика на устранение неполадок:

http://www.codinghorror.com/blog/archives/001198.html

Answer 6

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

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