Java Heap ColdFusion отлично работает, когда открыто окно JRockit Console, но использование памяти резко возрастает, а затем вылетает при закрытии JRockit Console.

У нас возникли проблемы с нашим сервером ColdFusion и с правильной настройкой JRE. Чтобы выяснить, что с этим происходит, мы установили Oracle JRockit и переключили jvm.config, чтобы попытаться найти любые утечки памяти.

После того, как мы установили JRockit, наш сервер стал работать лучше, чем когда-либо. Мы держали программу и консоль JRockit открытыми в течение нескольких дней, а объем используемой памяти не превышал 200 МБ. Наконец, мы закрыли программу на сервере, и проблема с использованием памяти сразу же вернулась.

Вот снимок экрана Java Heap из FusionReactor, чтобы проиллюстрировать, что происходит.

Я не мог опубликовать это здесь, так как у меня пока недостаточно очков репутации: http://www.weblisters.com/icm/FusionReactorJavaHeap-JRockit-Console.png

Вот основные настройки из нашего файла jvm.config:

java.home=C:/Progra~2/Java/jrockit-jdk1.6.0_33-R28.2.4-4.1.0/jre  

java.args=-server -Xms1024m -Xmx1024m  -Xgc:parallel -Dsun.io.useCanonCaches=false -Dcoldfusion.rootDir={application.home}/ -XX:+HeapDumpOnOutOfMemoryError -Xmanagement:ssl=false,authenticate=false,autodiscovery=true

Эта ошибка возникла сразу после закрытия консоли Jrockit: Ошибка: недостаточно памяти для обработки этой команды в tsStartJavaThread (src / jvm / threads / vmthread / lifecycle.c: 1096).

Attempting to allocate 1G bytes There is insufficient native memory for the Java Runtime Environment to continue.

Кто-нибудь знает, почему сборка мусора (GC) работает намного лучше с открытым и запущенным окном JRockit Console? Мы не можем оставить его открытым в качестве постоянного решения.


person billvsd    schedule 03.08.2012    source источник
comment
Какие команды вы использовали, чтобы открыть консоль? какой был синтаксис?   -  person Mark A Kruger    schedule 04.08.2012
comment
Я подозреваю, что Jrocket вытесняет ваши аргументы Java, и вы работаете с разными настройками. Ошибка, которую вы получаете, указывает на то, что ваше оборудование ограничено в ресурсах. Для работы ему требуется 1 ГБ непрерывной физической памяти. Я довольно часто вижу эту ошибку на виртуальных машинах.   -  person Mark A Kruger    schedule 04.08.2012
comment
После дальнейшего исследования выяснилось, что использование памяти и производительность нашего сервера повышаются, когда мы запускаем инструмент утечки памяти внутри JRockit. Мы используем Oracle JRockit Mission Control из пользовательского интерфейса, мы щелкаем правой кнопкой мыши JVM для запущенного экземпляра CF, а затем нажимаем Start Memleak. При выполнении теста memleak использование памяти упало до ~ 48 МБ. Момент закрытия утечки памяти. После запуска Memleak   -  person billvsd    schedule 05.08.2012
comment
Это физический сервер с оперативной памятью 8 ГБ. К сожалению, наш хостинг-провайдер лицензирует нам только 32-разрядную версию CF 8 Enterprise. Эта ошибка была лишь одной из других ошибок, которые у нас были, например, нехватка памяти, когда сервер находился под более высокой нагрузкой.   -  person billvsd    schedule 05.08.2012
comment
При запуске JRockit и теста Memleak мы заметили, что загрузка страниц на нашем сервере может вызвать видимые скачки в использовании памяти, но сборщик мусора произойдет вскоре после этого. Мы отключили JRockit JRE и вернулись к JRE6.0_24 (32-разрядная версия).   -  person billvsd    schedule 05.08.2012
comment
-XX: + UseParallelGC, похоже, не выполняет сборку мусора. Мы добавили -XX: + UseConcMarkSweepGC, и, глядя на графики кучи, кажется, что он запускает GC каждые 15 секунд или около того. Я не уверен, почему использование памяти при запуске теста memleak будет 48 МБ, а обратно к CF с -XX: + UseConcMarkSweepGC выровняется примерно на 400 МБ.   -  person billvsd    schedule 05.08.2012
comment
Ваш опыт с мемликом обратный (ха). Предполагается, что тестирование Memleak улучшит вашу память? Странно! Что касается 32-битной версии - CF 8 Enterprise будет работать на 64-битной. Возможно, вам нужен другой хост (поговорите со мной!).   -  person Mark A Kruger    schedule 06.08.2012
comment
Мне также нравится этот разъем с низкой паузой во многих случаях. Но один совет, который у меня есть, заключается в том, что (если у вас не происходит сбой - а это было именно так), не слишком беспокойтесь о том, сколько памяти на самом деле используется. JVM захватывает память и освобождает ее способом, который может показаться случайным и отключенным от вашего приложения, трафика или чего-то еще. Но, очевидно, если вы терпите крах, это совсем другая история. Вот ссылка, которая может вам пригодиться по этой теме coldfusionmuse.com/index.cfm/2012/4/27/ - извините, если вы уже все это знаете - вы кажетесь мне довольно проницательным :)   -  person Mark A Kruger    schedule 06.08.2012


Ответы (1)


Я думал, что опубликую обновление резолюции, которая в итоге сработала для нас. Я не совсем уверен, почему GC, похоже, работает намного лучше при использовании JRockit (особенно во время теста на утечку памяти), но мы нашли настройку для машины JVM, которая, похоже, позволила нам контролировать частоту вызова GC. .

-Dsun.rmi.dgc.client.gcInterval=27000 -Dsun.rmi.dgc.server.gcInterval=27000

Эти две настройки позволяют нам специально вызывать GC так часто или так редко, как мы хотим, и нам нужно было изменить его настройку по умолчанию. Мы также обновили всю нашу строку java.args на основе нескольких замечательных статей в блогах (ссылки внизу). Вот наш обновленный java.args, на котором наш сервер работает так, как должен.

java.args= -server -DJINTEGRA_NATIVE_MODE -DJINTEGRA_PREFETCH_ENUMS -Xmx1024m -Xms1024m -XX:MaxPermSize=192m -XX:PermSize=192m  -XX:+UseParallelGC -Dsun.rmi.dgc.client.gcInterval=27000 -Dsun.rmi.dgc.server.gcInterval=27000 -Dcoldfusion.rootDir={application.home}/ -Djava.compiler=NONE -Xnoagent -Xdebug 

Статьи в блоге:

Trunkful.com CF_GEMS Как для настройки JVM, часть 1

Trunkful.com CF_GEMS Как для настройки JVM, часть 2

person billvsd    schedule 05.09.2012