Вы должны запустить JavaMissionControl или другой Profiler, чтобы увидеть свои фактические требования к памяти. Вы можете запустить JavaMissionControl на сервере, где установлена Java (и в пути), запустив «jmc» из командной строки, а затем подключившись к вашей локальной JVM. Вы также можете подключиться к удаленной JVM. Для получения дополнительной информации обратитесь к этой ссылке: http://www.oracle.com/technetwork/java/javaseproducts/mission-control/index.html
Обычно я устанавливаю максимальную память выше необходимой, max = 1GB кажется хорошей отправной точкой. Вы захотите просмотреть профиль памяти вашего приложения в течение периода типичной активности. Поймите, что когда вы устанавливаете начальный размер кучи размером 64 МБ, сборщик мусора запускает схему, которая не будет запускать крупную сборку мусора до тех пор, пока это не будет необходимо для повышения производительности (сбор мусора дорогой). В результате вы увидите, что память ползет с течением времени примерно до 80% от размера кучи (этот% настраивается). Как только порог будет достигнут, появится сборка мусора, и вы снова увидите, что потерянная память JVM снова падает.
Обычно я ищу уровень памяти, который используется последовательно после серии крупных сборщиков мусора. Итак, скажем, после запуска вашего приложения вы увидите, что использование твердотельной памяти после крупной сборки мусора постоянно падает до 40 МБ. Поэтому я обычно устанавливаю минимальный размер JVM примерно на эту сумму, так как я знаю, что мне всегда нужно как минимум столько, сколько нужно.
Теперь вы знаете достойную отправную точку для своих минимальных требований, так что будет максимальной потребностью в памяти? Ну, это требует немного больше профилирования, проб и ошибок. То, что я делаю, начинает уменьшать максимальную настройку памяти ниже и профиль на некоторое время. То, что вы ищете, - это частота основных сборок мусора, а использование ЦП JVM достигает неизменно высоких значений.
Я бы постоянно уменьшал память до тех пор, пока не увижу большую сборку мусора, которая будет происходить несколько раз за короткий промежуток времени под нагрузкой, а процессор всплывет во время этих периодов сбора мусора. Как только я увижу это поведение, я постепенно увеличиваю максимальную память до тех пор, пока это поведение не прекратится, чтобы найти сладкое пятно максимальной памяти.
Это очень простой способ найти разумные значения для параметров памяти min/max и очень хорошо работает для меня в большинстве распространенных сценариев приложений. Конечно, есть много других более полных способов профилировать ваше приложение, чтобы точно настроить настройки памяти и схемы сбора/настройки мусора, если вы действительно хотите точно настроить свои требования.
Если я не устанавливаю никаких -Xms и Xmx, приложение получает кучу по умолчанию Java Solaris с InitialHeapSize: = 67108864 (64Mb) и MaxHeapSize: = 1073741824 (1GB). Через команду «prstat -a» приложение практически использует все (774Mb). В то же самое время, если я устанавливаю -Xms128m -Xmx128m, приложение отлично работает, так что это мой вопрос, как найти правильный объем памяти для него? Причина не устанавливает что-либо java работает, используя гораздо больше, чем нужно –
Я считаю, что это то, что я описываю в своем ответе ... как определить правильные значения для Xms и Xmx. – pczeus
Но есть ли причина, почему Java использует почти все доступные maxheap (1 ГБ), если Xmx не установлен, и в то же время, если установлено 128 Мб, приложение отлично работает? –