Содержание


Пять секретов... контроля производительности Java, часть 1

Профилирование производительности Java с помощью JConsole и VisualVM

Comments

Когда приложение работает медленно, большинство разработчиков впадает в панику, и тому есть веская причина. Поиск причин узких мест в Java-приложениях всегда было головной болью ― как потому, что виртуальная машина Java имеет свойства "черного ящика", так и потому, что на платформе Java традиционно недоставало инструментов профилирования.

Однако с появлением JConsole в Java 5 все изменилось. JConsole – это встроенный профайлер производительности Java, который работает из командной строки и в GUI-оболочке. Он не идеален, но служит более чем достаточной первой линией обороны, когда босс указывает вам на проблему производительности — и это гораздо лучше, чем консультироваться у Google.

В этой статье из цикла 5 секретов… я продемонстрирую пять простых способов использования инструмента JConsole (или его визуально продвинутого собрата VisualVM) для мониторинга производительности Java-приложений и отслеживания узких мест в коде Java.

1. JDK поставляется с профайлером

Развить навыки по этой теме

Этот материал — часть knowledge path для развития ваших навыков. Смотри:

Многие Java-программисты не знают, что, начиная с Java 5, в JDK включен инструмент профилирования. JConsole (или, в более поздних версиях платформы Java, VisualVM) — это встроенный профайлер, запустить который так же легко, как компилятор Java. Достаточно вызвать jconsole из командной строки при наличии JDK в переменной PATH. В GUI-оболочке перейдите в каталог установки JDK, откройте папку bin и дважды щелкните на jconsole.

Когда профайлер появится (время зависит от версии Java и количества других Java-программ, работающих в данный момент), откроется диалоговое окно с запросом URL-адреса процесса, к которому следует подключиться, или списком локальных процессов Java — иногда содержащим сам процесс JConsole.

Работа с JConsole

В Java 5 Java-процессы по умолчанию не настроены на профилирование. При запуске аргумент командной строки -Dcom.sun.management.jmxremote указывает ВМ Java 5, что нужно открыть соединения, чтобы профайлер мог их найти. Когда JConsole следит за процессом, достаточно дважды щелкнуть на нем, чтобы начать профилирование.

Профайлеры вносят свои собственные издержки, так что полезно потратить несколько минут на то, чтобы оценить их. Простейший способ обнаружить издержки JConsole - сначала запустить приложение отдельно, а затем под профайлером, и измерить разницу в производительности. (Приложение не должно быть слишком большим или слишком маленьким, мой любимый пример - SwingSet2, который поставляется с JDK). Я сначала попробовал запустить SwingSet2 с параметром -verbose:gc, чтобы увидеть циклы сбора мусора, а затем запустил то же приложение с подключенным к нему профайлером JConsole. С JConsole наблюдалась регулярная последовательность циклов GC, которой в противном случае не было. Это издержки производительности профайлера.

2. Дистанционное подключение к процессам

Профайлеры Web-приложений предполагают связь через сокет, поэтому достаточно небольшой настройки, чтобы JConsole (или любой профайлер на основе JVMTI) контролировал/профилировал удаленные приложения.

Например, если Tomcat работает на компьютере с именем webserver, и JMX на этой JVM включен и прослушивает порт 9004, то чтобы подключить к нему JConsole (или любой другой JMX-клиент), нужно указать URL-адрес JMX service:jmx:rmi:///jndi/rmi://webserver:9004/jmxrmi.

По сути, все, что требуется для профилирования сервера приложений, работающего в удаленном центре обработки данных, — это URL-адрес JMX. (Подробнее об удаленном мониторинге и управлении с помощью JMX и JConsole см. в разделе Ресурсы.)

3. Отслеживание статистики

В JConsole есть несколько вкладок, полезных для сбора статистических данных, в том числе:

  • Memory: для наблюдения за работой различных куч в сборщике мусора JVM;
  • Threads: для изучения текущей работы потоков в целевой JVM;
  • Classes: для наблюдения за общим количеством загруженных классов ВМ.

Эти вкладки (и соответствующие графики) основаны на объектах JMX, которые каждая ВМ Java 5 и выше регистрирует в JMX-сервере, встроенном в JVM. Полный список модулей в составе данной JVM приведен на вкладке MBeans вместе с некоторыми метаданными и ограниченным пользовательским интерфейсом для просмотра этих данных и выполнения операций. (Однако регистрация для получения уведомлений выходит за рамки пользовательского интерфейса JConsole.)

Использование статистики

Допустим, что процесс Tomcat "тормозит" из-за ошибок типа OutOfMemoryError. Чтобы узнать, что происходит, откройте JConsole, щелкните на вкладке Classes и следите за количеством классов. Если их число неуклонно возрастает, можно предположить, что где-то в сервере приложений или вашем коде есть утечка ClassLoader, и в скором времени пространство PermGen будет исчерпано. Если требуется дальнейшее подтверждение проблемы, проверьте вкладку Memory.

4. Создание дампа кучи для автономного анализа

В производственной среде часто все происходит очень быстро, и нет времени на то, чтобы поработать над приложением с профайлером. Вместо этого можно сделать снимок текущего состояния всего содержимого среды Java и сохранить его для последующего анализа. Это можно сделать в JConsole, а еще лучше ― в VisualVM.

Начните с перехода на вкладку MBeans, где нужно раскрыть узел com.sun.management, а затем HotSpotDiagnostic. Выберите Operations, и вы увидите кнопку dumpHeap на правой панели. Если в первом поле ввода (String) указать dumpHeap имя файла для дампа, он сделает снимок текущего состояния всей кучи JVM и сохранит его в этом файле.

Позднее можно использовать различные коммерческие профайлеры для анализа файла или VisualVM ― для анализа снимка. (Помните, что VisualVM присутствует в Java 6, а также доступен для отдельной загрузки).

5. JConsole ― не предел мечтаний

Профайлер JConsole хорош, но есть инструменты получше. Некоторые содержат аналитические дополнения или отличаются удобным пользовательским интерфейсом, другие по умолчанию отслеживают больше данных, чем JConsole.

В JConsole хорошо то, что вся программа написана на «старом добром языке Java»: такую утилиту мог бы написать любой Java-программист. В JDK даже входит пример того, как настроить JConsole, создав новый плагин для него (см. раздел Ресурсы). В VisualVM, построенном поверх NetBeans, концепция плагинов идет гораздо дальше.

Если JConsole (а также VisualVM или любой другой инструмент) ― совсем не то, что вам нужно, или отслеживает не то, что вы ищете, или не так, как вам хочется, то можно попробовать написать свой собственный. И если Java-код кажется слишком громоздким, всегда под рукой Groovy, JRuby или любой из десятка других языков JVM, которые помогут вам сделать это быстрее.

На самом деле достаточно простого инструмента на основе командной строки, подключенного через JMX, который позволяет точно отслеживать интересующие вас данные, именно так, как вам нужно.

Заключение

Мониторинг производительности Java не заканчивается на JConsole или VisualVM — в JDK скрывается целый ряд инструментов, о которых большинство разработчиков и не подозревает. В следующей статье этого цикла мы рассмотрим некоторые экспериментальные средства на основе командной строки, которые помогают "нарыть" больше данных о производительности. Поскольку эти инструменты обычно ориентированы на конкретные данные, они компактнее и легче полного профайлера и поэтому сами меньше влияют на производительность.


Ресурсы для скачивания


Похожие темы


Комментарии

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

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=40
Zone=Технология Java
ArticleID=841496
ArticleTitle=Пять секретов... контроля производительности Java, часть 1
publish-date=10192012