Недавно у меня появился VPS-сервер, и я использую Coldfusion, сайт работал нормально, пока не получал все больше и больше трафика, и я начал сталкиваться с исключениями OutOfMemory.
Думал просто поднять память VPS сервера, но это не помогло.
После нескольких поисков в Google я нашел параметр в настройках администратора CF для установки памяти кучи JVM. Это было стандартно: максимальный размер кучи 512 МБ, а минимальный размер кучи был пуст. Немного поигравшись, я теперь установил его на Min 50MB и Max 200MB, хорошо то, что я больше не получаю исключения OutOfMemory. Все идет нормально!
Но когда на сайте около 50 активных посетителей, он начинает замедляться. Использование ЦП составляет всего около 8% (диспетчер задач Windows), также диспетчер задач показывает только около 30% используемых 3 ГБ ОЗУ.
Поэтому я думаю, что мои значения можно изменить, чтобы использовать больше оперативной памяти. Честно говоря, я не понимаю этих настроек кучи памяти JVM, поэтому я понятия не имею, какой параметр подходит для меня.
Я нашел сценарий CF, который отображает использование памяти, подробности:
Heap Memory Usage - Committed 194 MB
Heap Memory Usage - Initial 50.0 MB
Heap Memory Usage - Max 194 MB
Heap Memory Usage - Used 163 MB
JVM - Free Memory 31.2 MB
JVM - Max Memory 194 MB
JVM - Total Memory 194 MB
JVM - Used Memory 163 MB
Memory Pool - Code Cache - Used 13.0 MB
Memory Pool - PS Eden Space - Used 6.75 MB
Memory Pool - PS Old Gen - Used 155 MB
Memory Pool - PS Perm Gen - Used 64.2 MB
Memory Pool - PS Survivor Space - Used 1.07 MB
Non-Heap Memory Usage - Committed 77.4 MB
Non-Heap Memory Usage - Initial 18.3 MB
Non-Heap Memory Usage - Max 240 MB
Non-Heap Memory Usage - Used 77.2 MB
Free Allocated Memory: 30mb
Total Memory Allocated: 194mb
Max Memory Available to JVM: 194mb
% of Free Allocated Memory: 16%
% of Available Memory Allocated: 100%
Мои аргументы JVM:
-server -Dsun.io.useCanonCaches=false -XX:MaxPermSize=192m -XX:+UseParallelGC - Dcoldfusion.rootDir={application.home}/../ -Dcoldfusion.libPath={application.home}/../lib
Могу ли я дать JVM больше памяти? Если да, то какие настройки мне следует использовать?
Огромное спасибо!!
Ответ, конечно, «это зависит» от вашего приложения. Первым шагом будет наблюдение за использованием памяти. Есть много продуктов, которые могут помочь: SeeFusion, Fusion Reactor ... плюс стандартный мониторинг JVM, такой как jconsole и VisualVM.
Выясните, каково ваше текущее использование кучи, и увеличивайте его, пока GC не станет более стабильным. Также убедитесь, что ваше пространство PermGen достаточно велико (если вы используете фреймворк или много объектов, это может быть проблемой).
На практике я фактически уменьшил размер кучи, когда наши приложения не приблизились к
Действительно хороший справочник по GC и производительности - это Oracle GC Tuning whit.
http://www.oracle.com/technetwork/java/gc-tuning-5-138395.html
В общем, чем больше памяти вы можете выделить для JVM, тем лучше. Чем больше вы установите для молодого поколения (примерно вдвое меньше общего размера виртуальной машины), тем лучше. Я играл с JVM размером до 28 ГБ.
Для мониторинга вы хотите использовать jconsole (если вы системный администратор, он ужасно интерфейс, инструментирован и ограничивает, но это то, что у вас есть) и, в частности, наблюдать за вашей деятельностью GC и общим количеством разверток. Это также даст вам представление о том, как выглядят ваши шаблоны использования памяти. Это монитор графического интерфейса, реализованный на 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 так, чтобы у вас не закончилось место. Здесь хранятся постоянные объекты (в основном классы), и когда у вас заканчивается пространство, это обычно плохо.
Система, вероятно, начинает замедляться при более высокой нагрузке из-за более частой сборки мусора, необходимой для сохранения такого маленького размера кучи.
Максимальный размер кучи буквально ограничивает максимальный объем памяти, потребляемой JVM; если вы хотите, чтобы у него было больше оперативной памяти системы, вам нужно увеличить максимальный размер кучи.
Однако, если программное обеспечение пережевывает такой объем памяти и требует такой большой сборки мусора, то, возможно, вы откладываете неизбежное только с большим размером кучи. Попробуйте установить более высокое значение (начните с 1024 МБ, затем перейдите к 2048 МБ), но если это только задерживает сбой, вам необходимо оптимизировать код приложения, чтобы он был более мягким с точки зрения использования ОЗУ.
Кай собрал этот отличный набор информации о настройке JVM. 50 мин и 200 макс - это довольно мало. Я предлагаю (на 32-битной версии) попробовать 1024 как максимальное, так и минимальное значение и посмотреть, как у вас дела.