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

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

Ругать плохой код (или плохих программистов) бесполезно – это не поможет найти узкие места и улучшить производительность Java™-приложений, как и попытки действовать "методом тыка". Тед Ньюард предлагает вашему вниманию инструменты мониторинга производительности Java, начиная с пяти советов по использованию для сбора и анализа данных о производительности JConsole, встроенного профайлера Java 5.

Тед Ньюворд, директор, Neward & Associates

Тед Ньюворд (Ted Neward) является директором компании “Neward & Associates”. Он занимается консультированием, преподаванием и презентациями продуктов на основе Java, .NET, XML-сервисов и других платформ. В настоящее время он живет недалеко от Сиэттла, штат Вашингтон.



19.10.2012

Об этом цикле статей

Вы думаете, что знаете о Java-программировании все? На самом деле большинство разработчиков только скребет по поверхности платформы Java, изучив ее лишь настолько, чтобы выполнять свою работу. В этом цикле статей Тед Ньюард углубляется в функциональные возможности платформы Java, выявляя малоизвестные факты, которые могут помочь в решении самых заковыристых задач программирования.

Когда приложение работает медленно, большинство разработчиков впадает в панику, и тому есть веская причина. Поиск причин узких мест в 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 или VisualVM?

JConsole входит в каждый выпуск платформы Java, начиная с Java 5. VisualVM — это усовершенствованный профайлер, основанный на платформе NetBeans, который впервые появился где-то в Java 6 update 12. Большинство организаций еще не перешли на Java 6 еще, поэтому данная статья посвящена JConsole. Однако большинство советов актуально для обоих профайлеров. Примечание. VisualVM не только включен в Java 6, но и предоставляется отдельно. См. раздел Ресурсы.)

Работа с 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. Отслеживание статистики

Нестандартный подход

На проблемы производительности в коде приложения реагируют по-разному, но все эти реакции предсказуемы. Те разработчики, которые программируют с первых дней Java, скорее всего, запустят старую IDE и начнут просматривать основные части базы исходного кода в поисках знакомых "красных флажков", таких как синхронизированные блоки, размещение объектов и т.п. Разработчик с меньшим стажем, вероятно, будет корпеть над флагами -X, которые поддерживает JVM, в поисках способов оптимизации сборщика мусора. А новички, конечно же, пойдут прямо в Google в надежде на то, что кто-нибудь уже нашел магический «ускоритель» JVM, и им не придется переписывать весь код.

Ни в одном из этих подходов нет ничего принципиально порочного, но все это действия наугад. Наиболее эффективное средство решение проблемы производительности — использование профайлера, а теперь, когда он встроен в платформу Java, отказу от этого нет никакого оправдания!

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

Ресурсы

Комментарии

developerWorks: Войти

Обязательные поля отмечены звездочкой (*).


Нужен IBM ID?
Забыли Ваш IBM ID?


Забыли Ваш пароль?
Изменить пароль

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Профиль создается, когда вы первый раз заходите в developerWorks. Информация в вашем профиле (имя, страна / регион, название компании) отображается для всех пользователей и будет сопровождать любой опубликованный вами контент пока вы специально не укажите скрыть название вашей компании. Вы можете обновить ваш IBM аккаунт в любое время.

Вся введенная информация защищена.

Выберите имя, которое будет отображаться на экране



При первом входе в developerWorks для Вас будет создан профиль и Вам нужно будет выбрать Отображаемое имя. Оно будет выводиться рядом с контентом, опубликованным Вами в developerWorks.

Отображаемое имя должно иметь длину от 3 символов до 31 символа. Ваше Имя в системе должно быть уникальным. В качестве имени по соображениям приватности нельзя использовать контактный e-mail.

Обязательные поля отмечены звездочкой (*).

(Отображаемое имя должно иметь длину от 3 символов до 31 символа.)

Нажимая Отправить, Вы принимаете Условия использования developerWorks.

 


Вся введенная информация защищена.


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