Пространство кучи Java Xmx Xms на сервере vServer с работающей оперативной памятью - PullRequest
Новая
       6

Пространство кучи Java Xmx Xms на сервере vServer с работающей оперативной памятью

3 голосов
/ 03 августа 2011

Мы запускаем сервер Minecraft, который использует Java, на сервере vServer, который имеет 1 ГБ гарантированной памяти и 4 ГБ оперативной памяти.

Мы запускаем Debian 6.0 (Squeeze) Minimal (64Bit) с веб-сервером lighttpd с php / mySQL вместе с реальным сервером Minecraft. В настоящее время у нас все настроено, чтобы оставаться в пределах нашей гарантированной оперативной памяти объемом 1 ГБ, но создается впечатление, что мы не используем преимущества оперативной оперативной памяти таким образом, и при этом мы не знаем, как (и если?) Мы должны это делать.

В настоящее время наш сервер загружается со следующей строкой: 

 /opt/java/jre/bin/java -Xmx880M -Xms880M
                        -XX:+UseConcMarkSweepGC
                        -XX:+CMSIncrementalPacing
                        -XX:ParallelGCThreads=2
                        -XX:+AggressiveOpts
                        -jar craftbukkit.jar nogui

Мы выделяем 880M для minecraft (мы думаем?), Остальное зарезервировано для системы, веб-сервера и т. Д. Как мы могли бы оптимизировать эту настройку? Имеет ли смысл распределять этот начальный запуск по 1 ГБ и в нашу работающую оперативную память? Есть ли способ для Java или системы справиться с этим самостоятельно, например, выделив более 880 МБ, когда это необходимо в часы пик, с максимальным объемом 4 ГБ? Поскольку работоспособная оперативная память не гарантируется, что произойдет, если она не будет доступна, когда это потребуется? Спасибо!

Ответы [ 2 ]

1 голос
/ 03 августа 2011

Как мы могли бы оптимизировать эту настройку?

Это зависит. Сначала вы должны профилировать использование памяти этим процессом. Добавить

-verbose:gc:file=gc_results.out

в вашей командной строке. Полученный файл данных gc можно открыть с помощью инструмента, подобного HPjmeter . Вы должны настроить кучу на основе среднего / пикового использования памяти. Не существует единого размера, который бы подходил для всей политики, которая была бы «оптимальной». Для начала выясните, сколько времени в среднем вы тратите на сборку мусора. Хорошее эмпирическое правило составляет <7%. Как часто вы запускаете Full GC? Ваша куча полна долгоживущих объектов или бомбардируется множеством недолговечных объектов? Эти вопросы должны определять ваше решение. </p>

0 голосов
/ 03 августа 2011

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

...