Вы должны запустить JavaMissionControl или другой Profiler, чтобы увидеть ваши фактические требования к памяти. Вы можете запустить JavaMissionControl на сервере, где установлена Java (и в пути), запустив «jmc» из командной строки, а затем подключившись к вашей локальной JVM. Вы также можете подключиться к удаленной JVM. Для получения дополнительной информации перейдите по этой ссылке: http://www.oracle.com/technetwork/java/javaseproducts/mission-control/index.html
Обычно я устанавливаю максимальный объем памяти выше необходимого, максимум = 1 ГБ кажется хорошей отправной точкой. Вы захотите посмотреть профиль памяти вашего приложения в течение периода типичной активности. Имейте в виду, что когда вы устанавливаете начальный размер кучи 64 МБ, сборщик мусора запускает схему, которая не запускает основную сборку мусора до тех пор, пока это не потребуется по соображениям производительности (сборка мусора требует больших затрат). В результате вы увидите, как объем памяти со временем увеличивается примерно до 80% от размера кучи (этот процент можно регулировать). Как только пороговое значение будет достигнуто, запустится сборка мусора, и вы увидите, что используемая память JVM снова упадет до очень низкого уровня.
Обычно я ищу уровень памяти, который постоянно используется после серии крупных сборок мусора. Итак, скажем, после запуска вашего приложения вы видите, что использование твердотельной памяти после крупной сборки мусора постоянно падает примерно до 40 МБ. Поэтому я обычно устанавливаю минимальный размер JVM примерно на эту сумму, поскольку я знаю, что мне всегда нужно как минимум столько же.
Теперь вы знаете достойную отправную точку для ваших минимальных требований, так какой же максимальный объем памяти потребуется? Ну, это требует немного больше профилирования и проб и ошибок. Что я делаю, так это начинаю уменьшать максимальную настройку памяти и профилировать на некоторое время. То, что вы ищете, - это частота основных сборок мусора и загрузка ЦП JVM, достигающая стабильно высоких значений.
Я бы постоянно уменьшал объем памяти до тех пор, пока не увижу, что основная сборка мусора происходит несколько раз за короткий период времени под нагрузкой, и в эти периоды сборки мусора резко возрастает нагрузка на ЦП. Как только я вижу это поведение, я медленно увеличиваю максимальную память, пока это поведение не прекратится, чтобы найти золотую середину необходимой максимальной памяти.
Это очень простой способ найти разумные значения для минимальных/максимальных настроек памяти, и он очень хорошо работает для меня в большинстве распространенных сценариев приложений. Конечно, есть много других более исчерпывающих способов профилирования вашего приложения для точной настройки как параметров памяти, так и схем/настроек сборки мусора, если вы действительно хотите точно настроить свои требования.
person
pczeus
schedule
12.02.2016