Вижу что пришло время рассказать про настройку JVM под Сервис деск сервер 4.5, т.к. всё больше появляется постов связанных с настройкой явы под сервер.
НР конечно давал рекомендации по настройке, но с того момента много времени прошло и JVM поднялась с 3 версии до 7, появилось другое "железо", а у кого и виртуалки.
Cразу хочу отметь, что настройки на разные платформы, операционные системы, да даже просто одинаковы сервера будут отличатся, так что то что хорошо для sun , совсем может не подходить для windows.
Так как я "живу" на Windows, то и все мои примеры будут связанны только с ним. Ява будет 1.6.30, т.к. в ней содержится много нового по алгоритмам и исправлены баги относительно работы с HotSpot.
Для полного понимания о JVM и HotSpot советую прочитать статьи Производительность Java SE 6 , Java HotSpot VM Options, Java Tuning White Paper.
Приготовьтесь к тому что это дело не на 5 минут, настройка потребует несколько дней, по простой причине что надо делать нагрузочные тесты, только тогда можно увидеть реальный результат.
Для настройки вам потребуется программный инструмент для анализа настройки и процессов, и лучше если он будет графический, тогда и картина происходящего будет яснее. Скачайте JDK или воспользуйтесь VisualVM. В JDK входит jvisualvm.exe, я буду использовать его. Это весьма неплохой софт предназначенный для настройки и нахождения "узких" мест в производительности приложений написанных Ява. Для работы с jvisualvm придётся остановить СД сервер если он работает как сервис и запустить его с командной строки или через bat, тогда jvisualvm сможет "увидеть" как работает jvm под нашим сервером.
Запустите jvisualvm и СД Сервер, в левой части окна увидите список работающих jvm, com.hp.startup.Bootstrap и есть запущенный сервер, можете сравнить по номеру pid с диспетчером задач.
Подключитесь к ней двойным кликом, в правом окне увидите текущую конфигурацию VM , начните с того что рекомендовано НР, тогда будет с чем сравнивать:
-XX:MaxNewSize=64M
-XX:NewSize=64M
-Xms200M
-Xmx1000M
Для анализа используйте закладки Monitor и Visual GC. Profiler и Sampler то же несут в себе ценную информацию, но они больше для разработчиков и могут им указать на разные проблемы в классах. Но мы их менять не будем , по этому и нет смысла смотреть на них, запуск анализаторов в этих табах под тормаживает jvm с которой они это читают.
Цель которую стоит преследовать, смотря на графики, увидеть избыточность конфигурации и её недостаточность в параметрах. Например, задав высокий уровень использования памяти виртуальной машиной, мы тем самым теряем в производительности и лишаем другие приложения этой же памяти.
И так первое что было вычитано из описания чтоб свести к минимуму потери связанные с переназначением размера памяти это назначить -Xms == -Xmx, -XX:PermSize == -XX:MaxPermSize.
Второе это воспользоваться одним из алгоритмов
• SerialGC: последовательная сборка молодого и старого поколений ( –XX:+UseSerialGC )
• ParallelGC: для молодого поколения использует параллельный копирующий GC, для старшего поколения параллельный Mark-Compact GC (-XX:+UseParallelGC -XX:+UseParallelOldGC)
• Concurrent Mark Sweep: для молодого поколения использует параллельный копирующий GC, для старшего поколения фоновый Mark-Sweep GC (-XX:+UseConcMarkSweep ).(Дока на эту тему).
Третье прочитайте и о других параметрах, не бойтесь их протестировать.
И так, что мы видим в нашем Visual GC. Область памяти Young generation (молодого поколения) состоит из трёх областей: Eden и двух меньших по размеру survivor spaces. Его очистка происходит часто и задавать очень большим размером эту область не стоит.
Большинство объектов создаются в области Eden, за исключением очень больших объектов, которые не могут быть размещены в ней и поэтому сразу размещаются в Old generation. В survivor spaces перемещаются объекты, которые пережили по крайней мере одну сборку мусора, но ещё не достигли порога 'старости' (tenuring threshold), чтобы быть перемещенными в Old generation.
Часть объектов из YouGen, когда она достигнет своего максимума, будет попадать в OldGen. Каким образом она туда попадает, т.е. с компрессией или просто копируется, зависит от алгоритма. Смысл переписывать статьи на эту тему не вижу, просто прочитайте их. А вот сама очистка OldGen занимет больше времени чем YouGen, по этому если такое у вас происходит часто, то надо это избегать и перестроить размер или заменить алгоритм. Если от остаётся долгое время(день) не заполненным(заполнено процентов 20), то есть смысл подумать об уменьшении его размера.
Для нагрузочного тестирования используйте старый клиент и вот почему - он в нём есть!, жаль что в нового они их не добавили в код. Есть три ключа /viewtest - тест бегает по всем элементам по деф. вьшкам, /opentest - бегает по всем деф. формам, надо быть окуратным с этим тестом в том плане что если есть рулы пишущие в форму при открытии, то тест просто остановится в ожидании от вас подтверждения сохранить или нет, /stresstest - это оба теста вместе. Тест лучше запускать пользователями, а не использовать системный акаунт. Запустите несколько клиентов на удалённой машине, но только не на сервере, и пусть они бегают по кругу вам только надо смотреть что происходит в VM.
Вот при стандартной(рекомендуемой) конфигурации я запустил тест два клиента с тестом и на графике видно как Heap начинает использоваться и сразу понятно что 200 это мало.
А PermGen деф. 15м просто не выдержал и начал расти.
Для своей конфигурации(win2003|2 x Xeon3.0Gh|2Gb) я нашёл следующий подходящий список параметров: -Xmx512m -Xms512m -Xmn256m -Xss128k -XX:PermSize=32m -XX:MaxPermSize=32m -XX:+UseConcMarkSweepGC -XX:+UseParNewGC -XX:SurvivorRatio=2 -XX:TargetSurvivorRatio=90 -XX:+AggressiveOpts -XX:+UseAdaptiveGCBoundary -XX:+UseBiasedLocking -XX:MaxTenuringThreshold=4 -XX:CompileThreshold=32
Производительность поднялась, по бенчу показывает процентов 10-15%, но "на глаз" видно что это сильно помогло View, сами формы по прежнему открываются также.
Есть две версии виртуальной машины — Client и Server, сервер поставляется только с JDK. Различие заключается в том что клиент строго ориентирован на работу на клиентских машинах, в сервере убрана часть проверок и он работает по иному с Heap чем клиент. Так что можно поиграть и с переключением VM на другой тип. При отладке можно просто добавить аргумент -server в командную строку и VM сама прогрузит серверный вариант. Если будете использовать этот тип в дальнейшем в сервисе, то достаточно указать другую dll при загрузке сервиса.
Загрузка vm сервера происходит дольше, но обработка идёт быстрее. Так бенч от клиента показывает при использовании -client 1300ms для сервера, а при -server 560ms при загрузке сервера в 50 пользователей.
Здесь был показан пример для сервера приложений, но ничто вам не мешает от тюнинговать и SSP, и WebConsole, и другие приложения которые крутятся на ява.
По большому счёту, всё что здесь сказано это работа для отдельной позиции - Performance admin, но такой нет и приходится заниматься самим. Так что если желание не пропало, то можете приступать.