Хорошо ли устанавливать максимальный и минимальный размер кучи JVM одинаковыми? - PullRequest
31 голосов
/ 28 июля 2011

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

Ответы [ 5 ]

26 голосов
/ 25 апреля 2014

Ответ Питера верен в том смысле, что -Xms выделяется при запуске, и он вырастет до -Xmx (максимальный размер кучи), но это немного вводит в заблуждение, как он сформулировал свой ответ. ( Извините, Питер, я знаю, вы знаете, что это холодно ).

Настройка мс == мх эффективно отключает это поведение. Хотя раньше это было хорошей идеей в старых JVM , это уже не так. Увеличение и уменьшение кучи позволяет JVM адаптироваться к увеличению нагрузки на память, но при этом сокращает время паузы за счет уменьшения кучи при уменьшении нагрузки на память. Иногда такое поведение не дает ожидаемых преимуществ с точки зрения производительности, и в этих случаях лучше установить mx == ms . OOME генерируется, когда куча превышает 98% времени, потраченного на сбор, и коллекции не могут восстановить более 2% этого. Если вы не достигли максимального размера кучи, JVM просто вырастет так, что вы выйдете за эти границы. Вы не можете иметь OutOfMemoryError при запуске, если ваша куча не достигает максимального размера кучи и не отвечает другим условиям, которые определяют OutOfMemoryError.

За комментарии, которые пришли с тех пор, как я написал. Я не знаю, что показывает запись в блоге JMonitor , но это от сборщика PSYoung.

size_t desired_size = MAX2(MIN2(eden_plus_survivors, gen_size_limit()),
                           min_gen_size());

Я мог бы больше копаться, но готов поспорить, что найду код, который служит той же цели в реализациях ParNew и PSOldGen и CMS Tenured. На самом деле маловероятно, что CMS сможет вернуть память, если не было Concurrent Mode Failure. В случае CMF будет работать последовательный сборщик, который должен включать сжатие, после которого вершина кучи, скорее всего, будет чистой и, следовательно, может быть освобождена.

8 голосов
/ 28 июля 2011

Основная причина для установки -Xms - это если вам нужна определенная куча при запуске. (Предотвращает возникновение OutOfMemoryErrors при запуске.) Как упоминалось выше, если вам требуется, чтобы куча запуска соответствовала максимальной куче, - это когда вы ее сопоставите. В противном случае вам это не нужно. Просто просит приложение занять больше памяти, которая в конечном итоге может понадобиться. Наблюдение за использованием вашей памяти во времени (профилирование) во время нагрузочного тестирования и использования вашего приложения должно дать вам хорошее представление о том, что нужно для их установки. Но это не хуже, чтобы установить их одинаковыми при запуске. Для большинства наших приложений я фактически начинаю с чего-то вроде 128, 256 или 512 за мин (запуск) и одного гигабайта за макс (это не для приложений на сервере приложений).

Только что нашел этот вопрос о переполнении стека, что также может быть полезно побочный эффект для увеличения-maxpermsize-and-max-heap-size . Стоит посмотреть.

4 голосов
/ 28 июля 2011

AFAIK, установка обоих одинакового размера устраняет дополнительный шаг изменения размера кучи, который может быть в вашу пользу, если вы в значительной степени знаете, сколько кучи вы собираетесь использовать. Кроме того, большой размер кучи уменьшает количество вызовов GC до такой степени, что это происходит очень мало раз. В моем текущем проекте (анализ рисков по сделкам) наши двигатели риска имеют как Xmx, так и Xms с одинаковым значением, которое довольно велико (около 8Gib). Это гарантирует, что даже после целого дня работы двигателей GC практически не происходит.

Также я нашел интересное обсуждение здесь .

2 голосов
/ 29 июля 2011

Определенно yes для серверного приложения.Какой смысл иметь столько памяти, но не использовать ее?(Нет, это не экономит электроэнергию, если вы не используете ячейку памяти)

JVM любит память.Для данного приложения, чем больше у JVM памяти, тем меньше GC оно выполняет.Самое приятное то, что больше объектов умрет молодым, а меньшее - срок службы.

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

1 голос
/ 28 июля 2011

Из того, что я вижу здесь на http://java -monitor.com / forum / showthread.php? T = 427 тестируемая JVM начинается с настройки Xms, но БУДЕТ освобождать память, которая ей не нужна, и поднимает ее до отметки Xmx, когда это необходимо.

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...