Request Metrics тоже интересная штука. Я узнал, что существует некий стандарт Application Response Measurement (ARM) для профилирования приложений. В административной консоли можно указывать ARM-агентов. Это было бы замечательной возможностью выполнить задачу. К сожалению, в интернете я не смог найти бесплатных ARM-агентов, поэтому вариант с Request Metrics тоже пришлось временно отложить.
Мои дальнейшие попытки выявить узкое место были связаны с получением trace с Oracle, который используется WebSphere и прикручиванием JProfiler к JVM WebSphere Process Server.
воскресенье, 21 сентября 2008 г.
Попытки профилировать WebSphere продолжаются...
Странно, но почему-то хорошие идеи приходят в критических ситуациях быстрее, чем в других. Дело в том, что когда я понял, что с HProf у меня ничего не получается, то только тогда ко мне пришла идея обратиться к своим знакомым за советом. Они все равно не помогли в полной мере, но удивительно то, что я сразу к ним не обратился. Это могло бы съэкономить уйму времени на хождение по неправильным путям.
Вот, что было дальше. У WebSphere имеются встроенные средства "профилирования", помимо HProf, который встроен в JVM. Эти средства можно найти в административной консоли в разделе Monitoring and Tuning: Performance Management Infrastracture (PMI) и Request Metrics. Первое - это какой-то кусок от продукта Tivoli, а второе тоже что-то в ту сторону.
PMI я включил на уровне ALL и как оказалось он умеет профилировать EJB методы, т.е. собирает аггрегированную статистику (среднее и общее время проведенное в методе и количество вызовов для каждого EJB). Только есть одна проблема: не понятно как расшифрововать эту статистику. Дело в том, что профилируется WebSphere Process Server, а это такая бандура: под JVM запущен WebSphere Application Server, под ним WebSphere Process Server, который уже заворачивает нашу прикладную логику в свои системные EJB. Таким образом, наших java-методов, которые мы писали своими собственными руками не видно. Кроме того, PMI не строит дерево вызовов, что еще больше усложняет задачу анализа. В лучшем случае метрики PMI сможет прочитать разработчик, который помнит взаимосвязи вызовов.
Разборки с PMI я отложил до лучших времен.
Странно, но почему-то хорошие идеи приходят в критических ситуациях быстрее, чем в других. Дело в том, что когда я понял, что с HProf у меня ничего не получается, то только тогда ко мне пришла идея обратиться к своим знакомым за советом. Они все равно не помогли в полной мере, но удивительно то, что я сразу к ним не обратился. Это могло бы съэкономить уйму времени на хождение по неправильным путям.
Вот, что было дальше. У WebSphere имеются встроенные средства "профилирования", помимо HProf, который встроен в JVM. Эти средства можно найти в административной консоли в разделе Monitoring and Tuning: Performance Management Infrastracture (PMI) и Request Metrics. Первое - это какой-то кусок от продукта Tivoli, а второе тоже что-то в ту сторону.
PMI я включил на уровне ALL и как оказалось он умеет профилировать EJB методы, т.е. собирает аггрегированную статистику (среднее и общее время проведенное в методе и количество вызовов для каждого EJB). Только есть одна проблема: не понятно как расшифрововать эту статистику. Дело в том, что профилируется WebSphere Process Server, а это такая бандура: под JVM запущен WebSphere Application Server, под ним WebSphere Process Server, который уже заворачивает нашу прикладную логику в свои системные EJB. Таким образом, наших java-методов, которые мы писали своими собственными руками не видно. Кроме того, PMI не строит дерево вызовов, что еще больше усложняет задачу анализа. В лучшем случае метрики PMI сможет прочитать разработчик, который помнит взаимосвязи вызовов.
Разборки с PMI я отложил до лучших времен.
вторник, 16 сентября 2008 г.
Вчера я потратил целый день для того, чтобы выполнить профилирование WebSphere Process Server в кластерной конфигурации. Сразу скажу, что сделать это не получилось. История следующая.
WebSphere Process Server работает под IBM JVM 1.4.2 под AIX 5.3. JVM имеет встроенный профайлер HProf, который можно включить с помощью параметра -Xrunhprof. Меня интересовало время проведенное сервером в каждом методе, поэтому для профайлера были заданы следующие ключи -Xrunhprof:cpu=samples,file=/tmp/java.hprof,format=b,doe=n. "format=b" обеспечивает бинарный формат файла, что должно снизить дополнительную нагрузку на сервер, вызванную профилированием, "doe=n" обеспечивает запись в файл по мере поступления информации, а не после завершения виртуальной машины. Все эти параметры можно задать в консоли управления Deployment Manager'а.
Результат: сервер начинает стартовать, содержимое указанного файла пополняется, но в какой-то момент обновление логов прекращается и JVM будто замирает. Видимо профайлер становится слишком тяжелым для такого большого приложения как WebSphere Process Server.
Возможно спасение находится в использовании других профайлеров типа JProbe, OptimizeIt и т.д. Однако они в-первых платные, а во-вторых требуют установки на AIX. В идеальном случае хотелось бы найти такой профайлер, для установки которого достаточно прописать в classpath JVM путь к нужному jar-файлу. Вроде как JIP именно такой, однако заявляется, что для его использования нужен JVM 1.5.x, а это не мой случай...
WebSphere Process Server работает под IBM JVM 1.4.2 под AIX 5.3. JVM имеет встроенный профайлер HProf, который можно включить с помощью параметра -Xrunhprof. Меня интересовало время проведенное сервером в каждом методе, поэтому для профайлера были заданы следующие ключи -Xrunhprof:cpu=samples,file=/tmp/java.hprof,format=b,doe=n. "format=b" обеспечивает бинарный формат файла, что должно снизить дополнительную нагрузку на сервер, вызванную профилированием, "doe=n" обеспечивает запись в файл по мере поступления информации, а не после завершения виртуальной машины. Все эти параметры можно задать в консоли управления Deployment Manager'а.
Результат: сервер начинает стартовать, содержимое указанного файла пополняется, но в какой-то момент обновление логов прекращается и JVM будто замирает. Видимо профайлер становится слишком тяжелым для такого большого приложения как WebSphere Process Server.
Возможно спасение находится в использовании других профайлеров типа JProbe, OptimizeIt и т.д. Однако они в-первых платные, а во-вторых требуют установки на AIX. В идеальном случае хотелось бы найти такой профайлер, для установки которого достаточно прописать в classpath JVM путь к нужному jar-файлу. Вроде как JIP именно такой, однако заявляется, что для его использования нужен JVM 1.5.x, а это не мой случай...
Некоторое время я думал создавать мне персонализированный блог или анонимный. Первый вариант может способствовать повышению собственной популярности, если в нем писать умные вещи. Второй тоже может этому способствовать, но нужно в какой-то момент эффектно сказать: "Знаете вот тот парень, который писал, это я!".
Я решил сделать блог персонализированным. Теперь у меня проблема: мне нужно как-то определить какую информацию я могу разместить в блоге, а какую нет. Если учесть, что большую часть времени я провожу на работе и занимаюсь развитием нового направления бизнеса в компании, то любая информация, выложенная в блог, может стать полезной конкурентам.
Я решил сделать блог персонализированным. Теперь у меня проблема: мне нужно как-то определить какую информацию я могу разместить в блоге, а какую нет. Если учесть, что большую часть времени я провожу на работе и занимаюсь развитием нового направления бизнеса в компании, то любая информация, выложенная в блог, может стать полезной конкурентам.
Подписаться на:
Сообщения (Atom)