Диагностика Java. Подход IBM: Часть 5. Оптимизация приложения при помощи Health Center

Как легко и быстро исправить проблемы с производительностью, выявить проблемы с настройками и контролировать работу приложений Java

Health Center, входящий в состав средств мониторинга и диагностики для Java™ от IBM (IBM Monitoring and Diagnostic Tools for Java™) — это инструмент для слежения за работающими приложениями на Java. Он отображает все аспекты состояния системы на диаграммах, графиках и таблицах и дает рекомендации по устранению проблем. Health Center включает чрезвычайно экономный профайлер, визуализацию сборки мусора, профайлер для выявления конфликтов блокировок, а также просмотрщик настроек. Узнайте, как использовать это средство для диагностики и устранения проблем с производительностью, настройками и стабильностью в ваших приложениях.

Тоби Корбин, программист, IBM

Тоби Корбин (Toby Corbin) - программист, в настоящее время разрабатывает инструментарий RAS в IBM Java Technology Centre. Он поступил на работу в IBM в 2001 году и четыре года занимался разработкой поддержки национальных языков и глобализации для Java Runtime Environment, а затем два года вел разработку библиотек Swing и AWT.



Холли Камминс, Software Engineer, IBM

Холли Камминс (Holly Cummins) является разработчиком в Центре Технологий Java в IBM в Великобритании. Она работает с IBM в течение четырех лет и имеет докторскую степень по математике. У нее страсть к математическому моделированию, к "заковыристым" языкам и к непрактичной обуви. С каждым днем она все больше ненавидит брюссельскую капусту и растущие скриптовые программы, написанные сомнительным синтаксисом. Кроме того, хозяйка из нее не очень хорошая.



08.02.2012

Об этой серии статей

Серия Диагностика Java. Подход IBM посвящена новым инструментам IBM, которые могут помочь решить проблемы с приложениями на Java и повысить их производительность. Из каждой статьи вы можете извлечь новые знания, которые сразу же можно применить на практике.

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

Комментарии и вопросы о статьях следует направлять непосредственно авторам.

Что служит причиной проблем производительности приложения? Как их устранить, не будучи экспертом в оптимизации? Стабильно ли приложение? Разумно ли оно настроено? Health Center из набора средств мониторинга и диагностики для Java™— это новый инструмент IBM, разработанный, чтобы дать ответы на эти и другие вопросы. Он проверяет процесс сборки мусора, выполнение методов, синхронизацию приложений и настройку. В дополнение к информации, необходимой для диагностики проблем, экспертная система Health Center решит проблемы за вас, обеспечивая анализ, выявляя проблемные места, предлагая рекомендации и командные строки. Приложение Health Center настолько экономично расходует ресурсы, что его можно использовать в эксплуатационном режиме. В этой статье показано, как загрузить и установить Health Center и как использовать его для устранения проблем в ваших приложениях.

Начало работы с Health Center

Health Center поставляется в виде двух частей, клиента и агента; агент отправляет информацию об отслеживаемой JVM клиенту, клиент подключается к агенту и отображает в графическом интерфейсе информацию о состоянии работающего приложения на Java.

Требования к JVM

Инструмент Health Center предназначен для работы с JVM от IBM, Java 5 и выше. Ему требуется как минимум уровень Java 5 service refresh 8 или Java 6 service refresh 1. Чтобы его можно было использовать в эксплуатационных условиях, вам потребуется Java 5 service refresh 10 или Java 6 service refresh 5.

Установка клиента

Клиент Health Center является частью IBM Support Assistant (ISA). Для установки клиента:

  1. Загрузите и установите ISA Workbench.
  2. Запустите ISA Workbench и выберите в меню Update > Find New... > Tools Add-ons.
  3. В мастере Find new tools add-ons введите в поле для поиска health, а затем разверните раздел Twistie, чтобы отобразить пункт Health Center, как показано на рис. 1:
    Рис. 1. Установка Health Center в ISA
    Установка Health Center в ISA
  4. Выберите пункт "Health Center", щелкните Next и следуйте инструкциям, чтобы завершить установку. Далее перезапустите ISA.

Установка агента

После установки клиента необходимо загрузить из него и установить агент:

  1. Щелкните Analyze Problem на странице приветствия ISA.
  2. Выберите дочернюю вкладку Tools. Из списка установленных инструментов выберите IBM Monitoring and Diagnostic Tools for Java — Health Center, а затем щелкните Launch, чтобы открыть мастер подключения Health Center, изображенный на рис. 2:
    Рис. 2. Мастер подключения
    Мастер подключения
  3. Щелкните по ссылке Enabling the application for monitoring.
  4. На следующей странице щелкните Installing the Health Center agent into an IBM JVM.
  5. На странице Installing the Health Center agent into an IBM JVM щелкните по ссылке, соответствующей JVM, установленной в вашей системе, чтобы загрузить ZIP-архив с файлами агента.
  6. Распакуйте архив в корневую директорию той JVM, которую нужно отслеживать. Начиная с Java 6 service refresh 2 и Java 5 service refresh 8, агент Health Center поставляется с JVM. Однако прилагающийся агент может иметь не самую свежую версию, поэтому всё же лучше заменить имеющийся агент Health Center на новый. Укажите yes, если в процессе установки появится запрос на перезапись файлов.

Запуск отслеживаемого приложения

Чтобы начать отслеживать приложение с помощью Health Center, это приложение нужно запустить с опцией командной строки, которая задействует агент Health Center. Синтаксис этой опции зависит от вашей версии JVM:

  • Для Java6 SR5 и выше используйте -Xhealthcenter.
  • Для SR1 и выше используйте опции -agentlib:healthcenter -Xtrace:output=perfmon.out.
  • Для Java 5, SR10 и выше используйте -Xhealthcenter. В остальных случаях используйте -agentlib:healthcenter -Xtrace:output=perfmon.out.

Если вы не знаете версию установленной у вас Java, её можно вывести в консоль командой java -version, как показано на рис. 3:

Рис. 3. Отображение версии Java
Version listing from a Java 6 SR5 JVM

Более простой способ определения опции командной строки, которую нужно использовать — попробовать сначала -Xhealthcenter. Если это не сработает, попробуйте -agentlib:healthcenter -Xtrace:output=perfmon.out.

Если агент Health Center успешно запускается с вашим приложением, в консоль выводится сообщение. Например, на рис. 4 при запуске java -version с опцией -Xhealthcenter указано, что агент Health Center запущен на порте 1972. Агент обычно слушает порт 1972, но номер будет автоматически увеличен, если порт 1972 уже занят (например, другим агентом Health Center).

Рис. 4. Запуск java -version с включенным Health Center
Запуск java -version с включенным Health Center

После того как агент запущен, вы можете использовать клиент Health Center для отслеживания своего приложения и решения многих проблем производительности и настройки.


Пример №1: анализ и устранение проблем производительности

Оптимизацию производительности необходимо основывать на конкретных исходных данных. Кажется простой и заманчивой идея находить возможные улучшения производительности, изучая код приложения и сразу внося исправления. Однако преждевременная оптимизация может быть неэффективной и опасной. Оптимизированный код часто сложнее поддерживать, чем его более медленные, но более естественные аналоги. Также внесение таких оптимизаций требует затрат времени. Затраты на оптимизацию и трудности поддержки сильно оптимизированного кода несомненно целесообразны, если производительность повышается, однако часто оптимизации практически не дают прироста производительности. Оптимизации необходимо производить в тех областях, где они дадут ощутимый результат. Процесс определения моментов, где оптимизации имеют смысл — это процесс поиска узких мест.

Анализ проблем производительности

По сути все проблемы производительности вызваны ограничениями ресурсов. Речь может идти о производительности различных основных вычислительных ресурсов: процессора, памяти, ввода-вывода, блокировок. Приложения, ограниченные в использование ресурсов процессора, не могут получить достаточно процессорного времени для завершении той работы, которая от них требуется. Ограниченные в памяти приложения требуют больше памяти, чем доступно. Ограниченные во вводе-выводе приложения пытаются осуществлять ввод-вывод быстрее, чем может позволить система. В ограниченных блокировками приложениях несколько потоков борются за одну и ту же блокировку; синхронизация потоков приводит к конфликтам за блокировки. Системы всё больше распараллеливаются, поэтому синхронизация становится ограничивающим фактором для их масштабирования.

Обнаруживая узкое место, вы определяете, какой ресурс ограничен. У Health Center имеется ряд возможностей для исследования и диагностирования плохой производительности приложений. Анализ производительности — это процесс поиска узкого места, его исправления, затем определения следующего узкого места, исправления, и так до тех пор, пока производительность приложения не станет удовлетворительной. Health Center автоматизирует многие процессы, необходимые для определения того, какой именно из ресурсов ограничен. Пока он не может анализировать использование ввода-вывода, но предоставляет отображение данных и советы по использованию процессора, памяти и блокировок.

Вид Status в Health Center отображает панель управления с индикатором для каждого потенциально ограниченного ресурса. Красным или оранжевым цветом помечаются области, в которых производительность приложения может быть улучшена. На рис. 5 показан исходный вид Status:

Рис. 5. Вид Status
Вид Status

Исследование сборки мусора

Чрезмерная сборка мусора является распространенной причиной плохой производительности приложений. Сборка мусора — это процесс, который JVM использует для автоматического управления памятью приложения. Он дает огромные преимущества с точки зрения безопасности и простоты кода и часто даже с точки зрения производительности. Однако сборщик мусора использует вычислительные ресурсы, поэтому необычные режимы использования памяти приложением либо неправильно настроенные размеры кучи могут сделать сборщик мусора чрезвычайно узким местом для производительности.

Health Center предоставляет подробный отчет о деятельности сборщика мусора и рекомендации по его настройке. На Рис. 6 показан вид Garbage Collection в Health Center. Он содержит отображение используемой кучи (это полезно для оценки использования памяти приложением) и время паузы (это полезно для оценки влияния сборки мусора на производительность). Также имеется сводная таблица со статистикой по сборке мусора и набор рекомендаций, в том числе, если требуется, предлагаемая командная строка.

Рис. 6. Вид Garbage Collection
Вид Garbage Collection

См. рисунок полностью здесь.

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

Рис. 7. Таблица, показывающая затраты на сборку мусора
Таблица, показывающая затраты на сборку мусора

Подходы к улучшению производительности сборки мусора

Влияние сборки мусора на производительность можно уменьшить несколькими способами. Во-первых, производить меньше мусора. Приложение создает объекты и тут же отбрасывает их? Строки часто конкатенируются без использования строковых буферов? Может ли автобоксинг создавать внутри нежелательные примитивные обертки? Создает ли код слишком большие объекты без необходимости? Также производительность можно улучшить, увеличив размер кучи, попробовав разные размеры пула первого поколения (для сборщиков с поколениями) и попробовав разные подходы к сборке мусора. Однако все эти методы требуют некоторой осмотрительности.

Например, следует осторожно подходить к наладке кода для улучшения сборки мусора. Некоторые оптимизации, кажущиеся хорошими, могут привести к ухудшению производительности. Например, заманчиво избежать постоянного создания объектов, просто повторно используя имеющиеся экземпляры. Однако безопасное управление пулом объектов может потребовать затрат на синхронизацию. Если размер пула неправильно настроен, многие неиспользованные экземпляры объектов останутся без дела и будут тратить память. Что еще более существенно, при сборщике мусора с поколениями (например, как в политике gencon policy) короткоживущие объекты убираются практически «бесплатно», в то время как удаление долгоживущих может быть очень затратным. Постоянное создание и отбрасывание объектов дает совсем небольшие затраты производительности, а если практиковать повторное использование имеющихся экземпляров объектов, от сборщика мусора потребуется значительная работа.

Другая ловушка в настройке сборки мусора — чрезмерно увлекаться понижением затрат на сборщик (см. рис. 7) и забывать, что конечная цель — это оптимизация производительности приложения. Хотя уменьшение затрат на сборку мусора обычно повышает производительность приложения, бывают и исключения. Например, время на сборку мусора с политикой gencon обычно больше, чем время на сборку мусора с политикой optthruput (см. раздел Ресурсы). Однако благодаря тому, как политика gencon размещает объекты в куче, она позволяет гораздо быстрее создавать объекты и получать к ним доступ. Так как приложения обычно тратят много времени на создание объектов и доступ к ним, во многих случаях прирост в производительности на этом (не отражаемый в статистике по затратам на сборку мусора) перевешивает дополнительные затраты на саму сборку. Еще более выделяется политика optavgpause , которая почти всю работу по сборке мусора производит параллельно, с совсем небольшими паузами в работе приложения. Это дает очень низкие затраты на сборку мусора, обычно намного меньше одного процента, а также прекрасный отклик приложения. Но скорость обработки данных не такая высокая, как с политиками optthruput или gencon.

Исследование конфликтов за блокировки

Конфликты за блокировки возникает, когда некоторая блокировка уже используется, а другой поток пытается получить к ней доступ. Серьезные конфликты могут вестись за блокировки, которые часто задействуются, либо используются в течение продолжительного времени, либо то и другое. Блокировка, за которую идет серьезная борьба (к которой пытаются получить доступ много потоков) может стать узким местом в системе, так как каждый из выполняющихся потоков останавливается до тех пор, пока необходимая блокировка не станет доступной, тем самым ограничивая производительность приложения. Синхронизация может особенно мешать масштабируемости приложения; чем больше в системе потоков, тем больше времени тратится на ожидание блокировок, а не на полезную работу. Health Center отображает деятельность блокировок и подсвечивает блокировки, которые отбрасывают запросы и потенциально влияют на производительность.

На рис. 8 показан вид Locking в Health Center:

Рис. 8. Вид Locking
Вид Locking

См. рисунок полностью здесь.

Чтобы понять график на рис. 8, нужно знать, что за данные в нём отображаются. Интенсивность цвета полоски на графике (от красного к зеленому) показывает, насколько серьезна борьба за неё. Блокировка, за которую идет сильная борьба, изображается ярко красным, а блокировка, за которую борьбы нет — ярко зеленым. Относительная высота каждой полоски показывает, какая из блокировок задействована больше других. Таким образом, цвет и высота вместе показывают, за какие блокировки борьба идет больше всего.

Блокировка может отображаться очень высокой полоской, но всё равно быть окрашена в зеленый цвет. Это означает, что, хотя она имеет большое количество отклоненных запросов, в среднем количество принятых запросов очень велико, поэтому процент отклоненных запросов небольшой. Но это всё равно может влиять на производительность. На графике блокировок на рис. 9 можно видеть две высокие оранжевые полоски:

Рис. 9. График блокировок
График блокировок

Две блокировки на рис. 9 являются основными кандидатами на дальнейшее исследование, так как обе полоски обозначают высокую интенсивность борьбы. Это самые высокие полоски, что говорит нам о том, что они имеют наибольшее количество отклоненных запросов, и они также по цвету близки к красному, что означает, что у них большой общий процент отклоненных запросов.

Подходы к улучшению производительности блокировок

Любые блокировки, занимаемые на длительное время, могут отрицательно влиять на производительность. Как можно уменьшить влияние на производительность таких блокировок? Первый шаг — определить, какой код использует проблемную блокировку. Health Center отображает класс блокировки. В некоторых случаях этого достаточно для точного определения блокировки, но не всегда. Например, если объект блокировки принадлежит классу Object, то поиск ссылок на него в коде может быть не таким простым. На рис. 10 показан анализ Health Center с различными блокировками класса DataStore и Object. Если Health Center указывает на проблему производительности, но из анализа Health Center неясно, какая именно блокировка вызывает проблемы, то можно использовать рефакторинг кода и ввести более выразительные имена для объектов блокировки, либо сделать несколько выводов java core для получения стеков вызова для наиболее популярных блокировок.

Рис. 10. Таблица блокировок
Таблица блокировок

Определив проблемные блокировки, необходимо переписать приложение с целью уменьшить конфликты за них. Проблему конфликтов за блокировку можно решить двумя способами: уменьшить количество времени, на которые забирается блокировка, что снизит вероятность конфликта, либо увеличить количество используемых объектов блокировки, чтобы каждый из них использовался в меньшем количестве контекстов (см. раздел Ресурсы).

Исследование выполнения кода

Раздел профиля методов указывает вам, на какой код приложение тратит время выполнения. (Если вместо выполнения вашего кода приложение ожидает блокировку или JVM собирает мусор, то программа это не указывает.) Если несколько методов используют непропорциональный объем процессорного времени, оптимизация этих методов может привести к значительным улучшениям производительности. На рис. 11 показан вид Profiling в Health Center. В него включена таблица наиболее активных методов, отсортированных по уровню активности (интенсивности), а также набор рекомендаций.

Рис. 11. Вид Profiling
Вид Profiling

См. рисунок полностью здесь.

Если ни один из методов не окрашен оранжевым или красным, то исполнение приложения распределено между методами относительно поровну. Всё же стоит оптимизировать наиболее интенсивные методы, так как они по-прежнему могут приводить к снижению производительности. Например, метод может слишком интенсивно использовать ввод-вывод. В нашем случае один из методов, очевидно, использует процессор более интенсивно, чем другие, поэтому он помечен красным. Из соответствующего значения в левой колонке "Self" на рис. 11 можно видеть, что 42.1% времени, в течение которого в JVM проверялось, чем занято приложение, оно выполняло метод DataStore.storeData(I). Колонка "Tree" справа показывает, сколько времени приложение тратило на метод DataStore.storeData(I) вместе с его дочерними вызовами. В простом однопоточном приложении 100% времени "Tree" тратилось бы в методе main().

Подходы к оптимизации кода

Цель настройки производительности — сделать так, чтобы приложение выполняло меньше работы. Так как большая часть работы производится в методах на верхнем уровне профиля методов, то эти методы и нужно рассматривать. Методы, находящиеся в нижней части профиля, можно без проблем игнорировать.

Дискретные и трассирующие профайлеры

Health Center создает профили методов на основе выборки стека вызовов каждые две миллисекунды — это т.н. дискретное профилирование. Некоторые профайлеры, известные как трассирующие, вместо этого отслеживают (трассируют) входы и выходы из методов. Это дает подробную информацию обо всех вызванных методах и их продолжительности, но налагает значительные затраты на профилируемое приложение. Выборка вместо трассировки — один из методов, с помощью которых Health Center достигает столь низких дополнительных затрат. Однако, поскольку дискретные профайлеры не знают, когда методы запускаются и завершаются, они не могут отличить метод, который часто появляется в стеке вызовов из-за того, что часто вызывается, от метода, который часто появляется в стеке вызовов из-за того, что долго выполняется.

Метод может появляться в верхней части профиля методов по двум причинам: либо метод вызывается слишком часто, либо он выполняет слишком много работы при вызове. Выполнение методов с циклами, особенно вложенными, может занимать много времени. Выполнение методов, содержащих много строк кода, также обычно занимает больше времени, чем выполнение очень коротких методов. Метод с небольшим объемом кода и без циклов, находящийся в верхней части профиля, скорее всего слишком часто вызывается.

Приложение можно оптимизировать, делая меньше работы в затратных по времени методах и реже вызывая часто вызываемые методы. Наиболее эффективный способ уменьшить объём работы в методах - переместить как можно больше кода за пределы циклов. Чтобы реже вызывать метод, нужно найти, какой код осуществляет вызовы, и убрать его. Часто, по крайней мере на первых этапах оптимизации, удивительно много вызовов затратного метода оказываются совершенно ненужными и могут быть просто исключены. При выборе метода в профиле в Health Center его путь вызова отображается в нижней части экрана. На рис. 12 показано, что 90.3% вызовов метода DataStore.storeData производится из метода StoreData.run:

Рис. 12. Дерево путей вызова
Дерево путей вызова

Рассмотрение различных интервалов времени

Иногда в какие-то периоды поведение приложения радикально меняется: сборка мусора происходит в безумном темпе, либо сильно ужесточается борьба за определенную блокировку, либо метод вырывается в первые позиции профиля методов. Health Center позволяет проводить анализ только для выбранного периода времени. При выделении прямоугольника на графике отображаемый период сужается. Соответственно сокращаются все виды Health Center. Рекомендации обновляются так, чтобы основываться только на выбранном периоде времени. Таблица профайлинга методов также обновляется с учетом показаний и процентов из выборки только для указанного периода времени. Это даёт возможность, например, увидеть только те методы, которые выполняются в тот момент, когда возникли проблемы со сборкой мусора, или исключить из анализа данные, касающиеся запуска приложения.


Пример №2: устранение проблем настройки

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

Health Center включает вид Environment, который отображает classpath, системные свойства и переменные среды для отслеживаемого приложения. Он также анализирует конфигурацию Java и дает рекомендации по возможным проблемам. Вид Environment показан на рис. 13:

Рис. 13. Вид Environment
Вид Environment

См. рисунок полностью здесь.

Какую JVM я использую?

Один из самых простых видов информации, отображаемой в виде Environment — это расположение отслеживаемой JVM. Удивительно, насколько часто этой информации бывает достаточно для решения проблемы. Недоступны ожидаемые классы? Характеристики производительности отличаются от ожидаемых? Изменения в файлах в JAVA_HOME (такие как настройки входа и безопасности, или изменения в библиотеках) не были приняты? В диагностике любых из этих проблем первое, что нужно проверить — совпадает ли работающая JVM с ожидаемой. В большинстве современных систем установлено много JVM, и большие приложения могут даже включать несколько разных JVM в разных местах.

С какими параметрами запуска я работаю?

Технология Java предлагает невообразимое множество опций командной строки. Некоторые из этих опций пригодны для определенных сред и непригодны для других. При развертывании современных приложений опции могут устанавливаться в нескольких вложенных скриптах запуска, и не всегда понятно, с какими опциями в результате выполняется приложение. Health Center предоставляет вид итоговой командной строки Java, который позволит вам выявить непредвиденные настройки приложения. Например, размер кучи может быть слишком сильно ограничен. Это может быть приемлемо для небольшого вспомогательного приложения, но может привести к падениям приложений, работающим с большими массивами данных в памяти. Если команда, отвечающая за падение приложения, не знает, что был установлен максимальный размер кучи, может быть сложно разобраться, почему памяти всегда не хватает. На рис. 14 показан вывод Health Center с набором опций командной строки:

Рис. 14. Вывод опций командной строки
Вывод опций командной строки

См. рисунок полностью здесь.

Health Center также анализирует настройки Java и помечает опции, которые могут иметь нежелательные последствия. Например, опции, которые были добавлены на тестовом этапе развертывания приложения, могли сохраниться при переходе к эксплуатации в реальных условиях. В частности, некоторые отладочные опции (такие как -Xdebug и -Xcheck) могут быть удобны для обнаружения проблем в ходе тестирования. Однако эти опции могут привести к накладным расходам, и их следует избегать, если необходима оптимальная производительность. Другие опции, такие как -Xnoclassgc, могут дать небольшой прирост производительности ценой риска бесконечного увеличения требований к памяти.

Достаточно ли у меня будет информации для анализа падений?

Не все проблемы с настройкой имеют отношение к командной строке Java. Некоторые обусловлены свойствами объемлющей системы. Наиболее значимые из них касаются ограничений на используемые процессом ресурсы в системах Linux® и AIX®. Использование процессора, количество потребляемой виртуальной памяти, размеры файлов и core-файлов можно ограничивать при помощи команды ulimit. Это может быть полезно, но также может затруднить диагностику проблем. Если core-файлы урезаются из-за того, что установлен слишком маленький ulimit, то из них практически невозможно извлечь осмысленную информацию. В некоторых системах настройки ulimit по умолчанию практически всегда дают урезанные core-файлы. (Core-файл — это образ процесса, который автоматически создается операционной системой, если процесс неожиданно завершается. Core-файлы необходимы для диагностики многих видов проблем с приложениями, в частности, падений.)

Так как core-файлы создаются только в случае возникновения проблем, о некорректных настройках ulimit обычно становится известно уже слишком поздно, когда JVM завершила работу, забрав с собой всю информацию, нужную для диагностики проблемы. Обычно единственный способ убедиться в том, что установки ulimit не мешают созданию полноценных core-файлов - предусмотреть возможность проблем и проверить установки ulimit вручную. К сожалению, это не идеальный вариант, так как он предполагает довольно нечеткие знания и множество предупредительных административных мер. Health Center автоматизирует выявление этой распространенной проблемы с удобством обслуживания. Благодаря Health Center нет надобности явно проверять установки ulimit — он выдает предупреждение, если установки необходимо подкорректировать.


Пример №3: Оценка стабильности вашей системы

Хотя в средах Java приложения падают не часто, они всё равно могут завершаться непредвиденным образом. Такие аварии вызываются рядом причин. Распространенная причина — код на Java обратился к "родному" коду через Java Native Interface (JNI), там произошел небезопасный доступ к памяти, и произошел общий сбой защиты (general protection fault, GPF). Другая распространенная причина — приложение на Java исчерпало кучу и больше не может выполняться. Также возможна ситуация, когда приложение на Java исчерпает родную память, что вызовет падение (см. раздел Ресурсы). Падения, вызванные исчерпанием памяти (либо кучи Java, либо родной), определяются по OutOfMemoryException.

Исследование утечки памяти

Большую часть падений невозможно предугадать, но некоторые можно. В частности, Health Center пытается предугадать падения, вызванные заполнением кучи Java. Health Center не может предупредить OutOfMemoryException, вызванное попыткой создать недопустимо большой объект. Однако большая часть OutOfMemoryException вызывается утечками памяти: хранением ссылок на память, которая больше не нужна. Эта память не может освобождаться сборщиком мусора. Если ненужные объекты продолжают накапливаться в куче, то рано или поздно не останется места под нужные объекты и будет выдано исключение OutOfMemoryException. На рис. 15 показано, как в Health Center отображается куча, используемая приложением с утечками. Требования приложения к памяти неуклонно растут, и Health Center выдает предупреждение, объясняющее, что рано или поздно возможно падение приложения.

Рис. 15. График предположительной утечки памяти
График предположительной утечки памяти

См. рисунок полностью здесь.

Как устранить утечку, которую уже выявил Health Center? В первую очередь необходимо определить, какие объекты используют утекающую память. Такого рода анализ лучше всего проводить на основе вывода кучи или системного вывода. Вывод создает для каждого объекта в куче запись о том, сколько памяти он использует и какие объекты на него ссылаются. Хранение ссылок на объекты, необходимость в которых отпала — самая распространенная причина утечек памяти в приложениях на Java.

Без специальных инструментов анализ кучи практически невозможен, и для этого существует ряд превосходных инструментов. Хотя Health Center не анализирует выводы, это делает другое приложение из семейства средств диагностики. Как и Health Center, инструмент Memory Analyzer из набора средств мониторинга и диагностики для Java от IBM можно бесплатно загрузить через ISA (см. раздел Ресурсы). Он предоставляет высокоуровневый обзор содержимого кучи, в том числе выявляет возможные утечки. Обычно одного этого уже достаточно для обнаружения причины утечки и ее устранения. На рис. 16 показан Memory Analyzer в действии:

Рис. 16. Memory Analyzer в ISA
Memory Analyzer в ISA

См. рисунок полностью здесь.

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


Заключение

Health Center предоставляет множество полезной информации о выполнении приложения, его стабильности и производительности. Он дает рекомендации по использованию сборки мусора, выявляет интенсивно работающие методы, выделяет области борьбы за блокировки и предоставляет информацию о среде, в которой работает приложение.

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

Ресурсы

Научиться

Получить продукты и технологии

  • Загрузите IBM Support Assistant serviceability workbench для доступа к полному набору средств слежения за приложениями Java и их диагностики, в том числе Health Center.

Комментарии

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=792150
ArticleTitle=Диагностика Java. Подход IBM: Часть 5. Оптимизация приложения при помощи Health Center
publish-date=02082012