Пользователь
Логин:
Пароль:
Забыли свой пароль?

Поиск по сайту
 

 Расширенный поиск
Реклама

Тюнинг виртуальной машины под СД сервер 4.5

Вижу что пришло время рассказать про настройку 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 то же несут в себе ценную информацию, но они больше для разработчиков и могут им указать на разные проблемы в классах. Но мы их менять не будем smile:), по этому и нет смысла смотреть на них, запуск анализаторов в этих табах под тормаживает 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), то есть смысл подумать об уменьшении его размера.

Для нагрузочного тестирования используйте старый клиент и вот почему - он в нём есть!smile:), жаль что в нового они их не добавили в код. Есть три ключа /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, но такой нет и приходится заниматься самим. Так что если желание не пропало, то можете приступать.