Coldfusion на VPS, сколько памяти JVM куча?
Недавно у меня был VPS-сервер, и я запускаю Coldfusion, веб-сайт работал нормально, пока не набирал все больший и больший трафик, и я начал сталкиваться с исключениями OutOfMemory.
Я думал просто поднять память VPS-сервера, но это не помогло.
После некоторых поисков в Google я нашел настройку в настройках de CF Admin, чтобы установить память кучи JVM. Это было по стандарту: максимальный размер кучи 512 МБ, а минимальный размер кучи был пуст. После того, как я немного поигрался, я установил значение Min 50MB и Max 200MB. Хорошо, что я больше не получаю исключения OutOfMemory. Все идет нормально!
Но с около 50 активных посетителей на сайте, сайт начинает работать медленно. Загрузка ЦП составляет всего около 8% (Windows Taskmanager), также диспетчер задач показывает только около 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 больше памяти? Если да, какие настройки я должен использовать?
Спасибо большое!!
4 ответа
Ответ, конечно, "это зависит" от вашего приложения. Первым шагом будет мониторинг использования памяти. Есть много продуктов, которые могут помочь: 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. GC отслеживает живые объекты в куче и работает, когда ParNew заполняется. Чем больше ParNew, тем больше времени проходит и больше объектов истекло (умерло), поэтому GC запускается реже, и больше объектов погибает. позволяя больше памяти быть GCd. У нас была конфигурация, в которой ParNew был установлен абсурдно маленьким (~50 МБ или около того), и увеличение его до 1-2 ГБ снизило накладные расходы GC примерно до 1-5% от того, что было ранее (0,01% - 2% ЦП). в зависимости от хоста / рабочей нагрузки сейчас составлял 10-50%).
Вы также захотите подобрать PermGen таким образом, чтобы вам не хватало места. Это место, где хранятся постоянные объекты (в основном, классы), и когда у вас заканчивается пространство, обычно это плохо.
Система, вероятно, начинает замедляться при более высокой нагрузке из-за более частой сборки мусора, необходимой для того, чтобы поддерживать кучу такой маленькой.
Максимальный размер кучи буквально ограничивает максимальный объем потребления памяти JVM; если вы хотите, чтобы у нее было больше оперативной памяти системы, вам нужно увеличить максимальный размер кучи.
Однако, если программное обеспечение перебирает столько памяти и требует столько мусора, вы, возможно, задерживаете неизбежное только с большим размером кучи. Попробуйте более высокую настройку (начните с 1024 МБ, затем перейдите к 2048 МБ), но если это только задерживает сбой, вам необходимо оптимизировать код приложения, чтобы он был более мягким с точки зрения использования ОЗУ.
Кай собрал этот замечательный набор информации о настройке JVM. 50 минут и 200 макс довольно низко. Я рекомендую (на 32-битной системе) попробовать 1024 как максимум и минимум и посмотреть, как вы идете.