Как сэкономить на использовании памяти с помощью опции Xmx JVM

Как определить нижнюю границу для параметра JVM Xmx или иным образом сэкономить память без проб и ошибок? Я устанавливаю Xms и Xmx равными одной и той же сумме, что, как я полагаю, помогает сэкономить время выполнения. Если я установлю Xmx на 7G, а также Xms, он с радостью сообщит, что все это используется. Я использую следующий запрос:

Runtime.getRuntime().totalMemory()

Если я установлю меньше этого, скажем, 5 ГБ, тоже будет использовано все. Только когда я предоставлю намного меньше, скажем, 1 ГБ, будет исключение из кучи. Поскольку мое время выполнения обычно составляет 10 часов и более, мне нужно избегать процессов проб и ошибок.


jvm memory jvm-arguments
person H2ONaCl    schedule 21.09.2013    source источник
comment
мое время выполнения обычно составляет 10 часов или более, тогда не устанавливайте Xms и позвольте JVM оптимизировать размер кучи для вас: это очень хорошо...   -  person assylias    schedule 21.09.2013
comment
И что потом? Периодически сообщайте об уровне паводка .totalMemory(), скажем, за 1 секунду, и используйте это число для установки Xmx?   -  person H2ONaCl    schedule 21.09.2013

Ответы (2)


arrow_upward
1
arrow_downward

Я бы выполнил программу с большим количеством кучи, отслеживая использование кучи с помощью JConsole. Обратите внимание на максимальное использование памяти после крупной сборки мусора и установите максимальный размер кучи на 50–100 % выше этого значения, чтобы избежать частой сборки мусора.

Кроме того, totalMemory сообщает о размере кучи, а не о том, сколько ее используется в настоящее время. Если вы установите минимальный и максимальный размер кучи на одно и то же число, totalMemory будет одинаковым независимо от того, что делает ваша программа...

person meriton    schedule 21.09.2013
comment
В моих экспериментах .totalMemory() является более изменчивым, чем .maxMemory(), поэтому я принял его за объем используемой кучи. Если, как вы предполагаете, totalMemory не является используемой кучей, то может показаться, что и maxMemory не меняется. - person H2ONaCl; 21.09.2013
comment
Я совершенно уверен, что прав, как говорится в javadoc Runtime.totalMemory: возвращает общий объем памяти, доступный в настоящее время для текущих и будущих объектов, измеренный в байтах. Поскольку будущие объекты включены, это должно включать в себя неиспользуемые в настоящее время области кучи. - person meriton; 21.09.2013

arrow_upward
0
arrow_downward

Используя Xms256M и Xmx512M и тривиальную программу, freeMemory составляет 244M, totalMemory - 245M, а maxMemory - 455M. Используя Xms512M и Xmx512M, получаем суммы 488M, 490M и 490M. Это говорит о том, что totalMemory является переменной величиной, которая может изменяться, если Xms меньше Xmx. Это предполагает, что ответ на вопрос состоит в том, чтобы установить Xms на небольшое количество и следить за максимальной отметкой totalMemory. Это также предполагает, что maxMemory — это предельный размер кучи, который не может превышать общее количество текущих и будущих объектов.

Как только высшая точка известна, установите Xmx на несколько большее значение из соображений осторожности, но не чрезмерно, потому что это усилие экономии, и установите Xms на такое же значение, чтобы получить явно предпочтительную эффективность использования времени.

person H2ONaCl    schedule 21.09.2013