Помогите мне стабилизировать эту конфигурацию jRun (CF9 / Win2k3 / IIS6) - PullRequest
Новая
       21

Помогите мне стабилизировать эту конфигурацию jRun (CF9 / Win2k3 / IIS6)

2 голосов
/ 20 мая 2010

Не уверен, что это лучше подходит для ServerFault, но, поскольку я не администратор, а разработчик, я решил попробовать SO.

Мы изо всех сил пытались сохранить нашу конфигурацию с несколькими серверами в течение достаточно долгого времени. В конце прошлого месяца мы работали под CF 7.0.2 на двух серверах (по одному экземпляру на каждом). В этот момент нам удалось довести время безотказной работы примерно до 1 недели на каждый экземпляр, прежде чем они перезагрузятся сами. С начала месяца мы повысили до CF 9 и вернулись на круги своя с многократным перезапуском в день.

Наша текущая конфигурация - 2 сервера Win2k3, на которых работает кластер из 4 экземпляров, по 2 экземпляра на сервер. На данный момент мы уверены, что это связано с неправильными настройками JVM.

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

По умолчанию: 

java.args=-server -Xmx512m -Dsun.io.useCanonCaches=false -XX:MaxPermSize=192m -XX:+UseParallelGC -Dcoldfusion.rootDir={application.home}/

На данный момент: 

java.args=-server -Xmx896m -Dsun.io.useCanonCaches=false -XX:MaxPermSize=512m -XX:SurvivorRatio=8 -XX:TargetSurvivorRatio=90 -XX:+UseParallelGC -Dcoldfusion.rootDir={application.home}/ -verbose:gc -Xloggc:c:/Jrun4/logs/gc/gcInstance1b.log

Мы определили, что нам нужно больше, чем стандартные 512 МБ, просто отслеживая с помощью FusionReactor, в среднем наш объем используемой памяти колеблется в середине 300 МБ и может увеличиться до 700 МБ при большой нагрузке.

Большая часть сбоя будет регистрироваться в jrun4 / bin / hs_err_pid * .log, всегда "Out of swap space"

Я со вчерашнего дня внизу поста прикрепил ссылки на файл журнала hs_err и сборщика мусора.

Соответствующая часть ( Я думаю ) это: 

Heap
 PSYoungGen      total 89856K, used 19025K [0x55490000, 0x5b6f0000, 0x5b810000)
  eden space 79232K, 16% used [0x55490000,0x561a64c0,0x5a1f0000)
  from space 10624K, 52% used [0x5ac90000,0x5b20e2f8,0x5b6f0000)
  to   space 10752K, 0% used [0x5a1f0000,0x5a1f0000,0x5ac70000)
 PSOldGen        total 460416K, used 308422K [0x23810000, 0x3f9b0000, 0x55490000)
  object space 460416K, 66% used [0x23810000,0x36541bb8,0x3f9b0000)
 PSPermGen       total 107520K, used 106079K [0x03810000, 0x0a110000, 0x23810000)
  object space 107520K, 98% used [0x03810000,0x09fa7e40,0x0a110000)

Из него я понимаю, что это PSPermGen, который заполнен (большинство журналов показывают то же самое перед сбоем), поэтому мы увеличили MaxPermSize, но общее количество по-прежнему отображается как 107520K! ??!

Никто здесь не является экспертом jRun, поэтому любая помощь или даже идеи о том, что делать дальше, будут с благодарностью !!

Файлы журнала: Извините, я знаю, что sendpace - не самое дружелюбное место - если у вас есть другие предложения хоста для файлов журналов, дайте мне знать, и я обновлю пост (ТАК, как они не нравятся встраиваемым, он взрывает формат поста).

Ответы [ 2 ]

2 голосов
/ 20 мая 2010

У этого эффекта может быть много причин - что угодно, от того, как построено ваше приложение (нетрадиционное использование области приложения или сервера? Неправильные драйверы баз данных и управление соединениями? Анализ гигантских файлов XML? Использование CFHTTP или других внешних ресурсов. «Проблемы с собственной репликацией сеансов») к вашим практикам кодирования (var scoping везде?) К типам процессоров на ваших серверах. Маловероятно, что вы придумаете какие-то настройки JVM «Волшебная пуля» без особого анализа (и, возможно, даже тогда). Но для начала, почему у вас такой необычно большой PermGen? Похоже на своеобразный шаблон, но, конечно, я ничего не знаю о вашем приложении.

Кажется, вам есть что терять, если вы попробуете несколько разных сборщиков мусора. Если соответствует вашей версии JVM, попробуйте: 

-XX:+UseConcMarkSweepGC -XX:+UseParNewGC

и добавьте: 

-XX:+CMSPermGenSweepingEnabled -XX:+CMSClassUnloadingEnabled

, что может помочь в управлении вашим большим PermGen. Не забудьте вынуть XX: + Используйте ParallelGC, если вы попробуете это.

1 голос
/ 02 июня 2010

Небольшое обновление. Я пробовал разные GC, и хотя некоторые из них некоторое время стабилизировали систему, она продолжала падать, но реже. Поэтому я продолжал копать и в конце концов обнаружил, что JVM выдает «Out of swap space», когда сама ОС отказывается выделять запрошенную память.

Это обычно происходит, когда максимальный объем памяти уже назначен процессу JVM, это издержки jrun, сама JVM, все библиотеки, куча И стек. Так как запрос находится в стеке, если у вас много запросов, то стек будет расти и расти. Размер каждого потока варьируется в зависимости от ОС и версии JVM, но может управляться с помощью аргумента -Xss. Я уменьшил наш до 64k, поэтому наш java.args выглядит так: 

java.args=-server -Xmx768m -Xss64k -Dsun.io.useCanonCaches=false -XX:MaxPermSize=512m -XX:+UseParallelGC -Dcoldfusion.rootDir={application.home}/ -verbose:gc -Xloggc:c:/Jrun4/logs/gc/gcInstance2a.log

До сих пор все было стабильно без какого-либо заметного замедления в течение 6 дней, что, безусловно, является самым длинным, которое я когда-либо видел, чтобы приложение работало Если вы слишком сильно уменьшите размер запроса, вместо ошибки OOM вы заметите ошибки переполнения стека в журнале.

Следующим моим шагом будет настройка MaxPermSize, но пока все хорошо!

...