Настройки кучи Java

Читая некоторые заметки по настройке производительности, я заметил рекомендации при установке размера памяти:

Приложение Java должно иметь одинаковое значение для начального и максимального размера постоянного поколения, поскольку для увеличения или сжатия постоянного пространства генерации требуется полный сборщик мусора. Аналогичное предложение дается при установке размера кучи, т.е. -Xmx=-Xms.

У меня вопрос: тогда почему у нас вообще есть параметр -Xms?

Кроме того, Почему сборщик мусора часто срабатывает, если у меня разные значения для -Xmx и -Xms, а не когда у меня одинаковый размер для -Xmx и -Xms.

Чтобы добавить больше к моему второму вопросу: Если я начну с минимального размера кучи 64 МБ и максимального 512 МБ, я считаю, что полный сборщик мусора не будет запущен, если память, используемая моим приложением, не достигнет 512 МБ.

Точно так же, если я начну с 512M для -Xmx и -Xms, JVM все равно будет запускать полный сборщик мусора, когда мое использование памяти приложения достигнет этого предела. Так почему же рекомендуется устанавливать для max и min одно и то же значение?


person Vicky    schedule 29.08.2012    source источник


Ответы (3)


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

Руководство не всегда идеально. Есть несколько видов приложений, в которых разумно позволить арене расти.

person Gene    schedule 29.08.2012
comment
Правильно ли это предположение, что даже если у нас одинаковые или разные размеры для min и max, ПОЛНЫЙ GC запускается только тогда, когда использование памяти достигает максимума. - person Vicky; 29.08.2012
comment
Это зависит от реализации коллектора. Точнее сказать, что арена будет расширена (и, следовательно, произойдет полный сбор), когда запрос на выделение не может быть удовлетворен. Это не обязательно означает, что вся память на арене используется вашей программой. Фрагментация (которая происходит по-разному в сборщиках поколений) может сделать память непригодной для использования, даже если она свободна. Фактически, полный сбор может произойти из-за фрагментации, даже если нижний и верхний пределы равны. Современные сборщики копий уменьшают шансы, но, как правило, они не равны нулю. - person Gene; 29.08.2012
comment
Спасибо .. Я заметил, что второстепенная или большая коллекция запускается еще до того, как загрузка достигает максимума, поэтому постепенно увеличивайте арену, пока она не достигнет максимума. - person Vicky; 14.09.2012

-Xms=64m -Xmx=512m не означает «запускать с кучей от 64 до 512 МБ». Он указывает JVM запрашивать 64 МБ выделенной памяти и 512 МБ зарезервированной памяти при запуске. Размер кучи для начала будет 64 МБ, и по мере заполнения она будет расширяться в зарезервированное для нее пространство. Итак, с Xms размером 64 МБ вы увидите полную коллекцию до того, как куча заполнится до 64 МБ.

Если вы запустите приложение с низким значением Xms и включите ведение журнала сборщика мусора (-verbose:gc -Xloggc:FILENAME), файл журнала покажет, как изменяются размеры кучи и генерации по мере выполнения приложения.

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

person Paul Medcraft    schedule 05.09.2012
comment
Хотел бы я принять два ответа. Но да ... все, что вы сказали, было правильным, и я проверил их на своей стеклянной рыбке. - person Vicky; 14.09.2012

Одна из причин использования -Xms ‹-Xmx состоит в том, чтобы позволить JVM не выделять заранее весь Xmx, чтобы разница была доступна (возможно, некоторое время) для других приложений. Подробности здесь: http://www.ibm.com/developerworks/library/j-memusage/

person David Soroko    schedule 06.11.2014