Coldfusion на VPS, сколько памяти "кучи" JVM?

Действительно хороший справочник по GC и производительности - это Oracle GC Tuning whit

http://www.oracle.com/technetwork/java/gc-tuning-5-138395. html

В общем, чем больше памяти вы можете выделить для вашей JVM, тем лучше. Чем больше вы установите для молодого поколения (примерно вдвое меньше общего размера виртуальной машины), тем лучше. Я играл с JVM размером до 28 ГБ.

Для мониторинга вы хотите использовать jconsole (если вы системный администратор, он ужасно интерфейс, инструментарий и ограничивает, но это то, что у вас есть) и, в частности, наблюдайте за своей деятельностью по ГХ и общим количеством разверток. Это также даст вам представление о том, как выглядят ваши шаблоны использования памяти. Это монитор графического интерфейса, реализованный на Java. Вам нужно будет включить расширения JMX в JVM, чтобы использовать его.

Чтобы узнать, что на самом деле использует память, Утилита 'jmap' покажет вам как размер кучи ('jmap -heap'), так и список («гистограмму») объектов в куче ('jmap -F -histo'). Первый обычно выполняется быстро, я видел второй запуск в течение 20–30 минут, в течение которых JVM не реагирует на другие задачи, так что это не то, что легкомысленно использовать в производственных экземплярах.

Как ни странно, , чем больше вы делаете свое ParNew / молодое поколение, тем реже, быстрее и эффективнее выполняется сборка мусора. GC работает, отслеживая живые объекты в куче, и запускается по мере заполнения ParNew. Чем больше ParNew, тем больше времени проходит и больше объектов истекло (умерло), поэтому сборщик мусора запускается реже и больше объектов умерло. позволяя больше памяти быть GCd. У нас была конфигурация, в которой ParNew был установлен абсурдно маленьким (~ 50 МБ или около того), и увеличение его до 1-2 ГБ снизило накладные расходы на сборку мусора примерно до 1-5% от того, что было раньше (0,01% - 2% ЦП в зависимости от хоста / рабочей нагрузки сейчас было 10-50%).

Вы я также захочу изменить размер PermGen так, чтобы у вас не закончилось место. Здесь хранятся постоянные объекты (в основном классы), и когда у вас заканчивается пространство, это обычно плохо.

Ответ, конечно, «это зависит» от вашего приложения. Первым шагом будет наблюдение за использованием памяти. Есть много продуктов, которые могут помочь: SeeFusion, Fusion Reactor ... плюс стандартный мониторинг JVM, такой как jconsole и VisualVM.

Выясните, каково ваше текущее использование кучи, и увеличивайте его, пока GC не станет более стабильным. Также убедитесь, что ваше пространство PermGen достаточно велико (если вы используете фреймворк или много объектов, это может быть проблемой).

На практике я фактически уменьшил размер кучи, когда наши приложения не пришли близко к

Система, вероятно, начинает замедляться при более высокой нагрузке из-за более частой сборки мусора, необходимой для сохранения такого маленького размера кучи.

Максимальный размер кучи буквально ограничивает максимальный объем памяти потребление JVM; если вы хотите, чтобы у него было больше ОЗУ системы, вы захотите увеличить максимальный размер кучи.

Однако, если программное обеспечение пережевывает такой объем памяти и требует такой большой сборки мусора, тогда вы можете только откладывая неизбежное с большим размером кучи. Попробуйте установить более высокое значение (начните с 1024 МБ, затем перейдите к 2048 МБ), но если это только задерживает сбой, вам необходимо оптимизировать код приложения, чтобы уменьшить использование ОЗУ.

Кай собрал большой набор информации о настройке JVM. 50 мин и 200 макс - это довольно мало. Я бы посоветовал (на 32-битной версии) попробовать 1024 как максимальное, так и минимальное значение и посмотреть, как у вас получится.