Диагностика Java в стиле IBM : Часть 2. Сборка мусора с использованием Garbage Collection and Memory Visualizer из инструментария IBM Monitoring and Diagnostic Tools for Java

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

Garbage Collection and Memory Visualizer® – новый инструмент от IBM, разработанный для выявления и анализа проблем производительности Java™, связанных с памятью. В данной статье (второй из четырех) описано, где приобрести данный инструментарий и как использовать его для быстрого выявления некоторых распространенных проблем.

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

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



03.10.2008

Есть несколько причин, по которым стоит поближе познакомиться со сборкой мусора в приложении. С использованием памяти приложением связан ряд важных вопросов. Не ли слишком много памяти расходует приложение? Нет ли утечек памяти? Рационально ли используется память при длительной работе? Интерес может представлять и ускорение работы приложения. Сборка мусора может сильно влиять на производительность приложения. Большинство программистов знает, что плохо сконфигурированная сборка мусора может вызывать перерасход ресурсов и замедлить работу программы. Однако обратное тоже верно: разумный выбор параметров сборки мусора может в действительности повысить производительность.

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

Garbage Collection and Memory Visualizer является частью нового набора инструментов от IBM, анализирующим подробные журналы сборки мусора и предоставляющим именно такую помощь при разрешении проблем с памятью. В данной статье описаны возможности Garbage Collection and Memory Visualizer и представлены примеры сценариев, в которых Garbage Collection and Memory Visualizer может помочь в определении проблем с памятью.

Garbage Collection and Memory Visualizer может обрабатывать журналы всех JRE от IBM, начиная с версии 1.4.2 и старше. Он позволяет также наглядно отображать журналы IBM WebSphere® Real Time. С его помощью можно сравнить сразу несколько журналов, выделяя определенные области журнала, фильтруя данные и выбирая единицы измерения. Вид экрана Garbage Collection and Memory Visualizer приведен на рисунке 1:

Рисунок 1. Вид экрана Garbage Collection and Memory Visualizer.
Рисунок 1. Вид экрана Garbage Collection and Memory Visualizer.

Подробная регистрация сборки мусора

Чтобы получить данные для анализа, необходимо включить для приложения режим подробной регистрации. Это можно сделать, установив флаг виртуальной машины (VM) -verbose:GC или использовав команду -XverboseGClog:файл для VM от IBM версии 5.0 или выше. Здесь файл является именем выбранного файла журнала. По возможности следует использовать опцию -XverboseGClog. Влияние подробной регистрации на производительность приложения относительно невелико.

Загрузка и установка Garbage Collection and Memory Visualizer

Об IBM Support Assistant

IBM Support Assistant (ISA) – бесплатное ПО, помогающее решать проблемы с программными продуктами IBM. ISA содержит средства поиска, который охватывает большой объем документации IBM и категоризируют полученные результаты для просмотра.

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

Панель инструментов (Tool workbench) ISA предоставляет диагностические инструменты, помогающие разрешать проблемы с продуктами IBM. Эти инструменты постоянно обновляются и дают возможность запускать диагностические средства на персональном компьютере. Ссылки для загрузки ISA приведены в разделе Ресурсы.

Garbage Collection and Memory Visualizer можно загрузить бесплатно вместе с IBM Support Assistant. Если этот продукт еще не установлен, нужно сначала загрузить его (см. раздел Ресурсы). Установив IBM Support Assistant, можно установить плагин Garbage Collection and Memory Visualizer. Garbage Collection and Memory Visualizer доступен для загрузки со страницы обновлений IBM Support Assistant на вкладке новых плагинов, в разделе Common Component Tools, как показано на рисунке 2:

Рисунок 2. Установка Garbage Collection and Memory Visualizer
Рисунок 2. Установка Garbage Collection and Memory Visualizer

В параметрах IBM Support Assistant необходимо также указать, что используется продукт, содержащий JVM. Для этого следует установить плагин, как показано на рисунке 3. Например, можно выбрать один из комплектов разработчика Java (JDK) из раздела Other или один из продуктов WebSphere из раздела WebSphere.

Рисунок 3. Установка плагина.
Рисунок 3. Установка плагина.

После установки нового плагина необходимо перезапустить IBM Support Assistant. Garbage Collection and Memory Visualizer будет доступен для запуска на странице Tools, как показано на рисунке 4:

Рисунок 4. Запуск Garbage Collection and Memory Visualizer
Рисунок 4. Запуск Garbage Collection and Memory Visualizer

Стандартные задачи

Теперь давайте выполним с помощью Garbage Collection and Memory Visualizer общий анализ журнала.

Открытие журнала для анализа

Для анализа подробной регистрации сборки мусора необходимо запустить Garbage Collection and Memory Visualizer и выбрать Open File из меню File. Garbage Collection and Memory Visualizer откроет журнал в редакторе с четырьмя вкладками, как показано на рисунке 5. Можно открыть журнал из работающего приложения, правда, автоматическое обновление экрана в Garbage Collection and Memory Visualizer не предусмотрено. Для обновления экрана Garbage Collection and Memory Visualizer следует щелкнуть на кнопке Reset Axes.

Рисунок 5. Вкладки редактора Garbage Collection and Memory Visualizer.
Рисунок 5. Вкладки редактора Garbage Collection and Memory Visualizer.

Имеются следующие вкладки:

  • Вкладка с именем файла отображает сами записи журнала. Если журнал большой, отобразится лишь часть текста, но анализироваться будет по-прежнему весь журнал.
  • Вкладка Data отображает сырые выходные данные Garbage Collection and Memory Visualizer. Эти данные можно копировать и вставлять в таблицы.
  • Вкладка Line Plot отображает диаграммы данных.
  • Вкладка Report содержит отчет Garbage Collection and Memory Visualizer по данным со сводкой по каждому выбранному полю, таблицу со сводкой по всему журналу и ряд рекомендаций по настройке.

В меню VGC Data, показанном на рисунке 6, отображаются все доступные для просмотра поля. Серым отображены поля, которые не были найдены в текущем журнале. Для отображения общей таблицы сводки необходимо выбрать поле Summary. Таким же образом для получения рекомендаций необходимо включить пункт Tuning Recommendation.

Рисунок 6. Меню данных VGC.
Рисунок 6. Меню данных VGC.

Сравнение нескольких файлов

Garbage Collection and Memory Visualizer дает возможность сопоставить несколько файлов. Это удобно для оценки результатов сделанных изменений. На рисунке 7 показана работа приложения, выполняющего одну и ту же задачу при трех различных политиках сборки мусора. (В данном случае в качестве приложения выступает сам Garbage Collection and Memory Visualizer). Сплошной линией изображена политика сборки мусора gencon, точками – политика optavgpause, пунктирной – политика optthruput. Garbage Collection and Memory Visualizer составляет метки линий на основе имен файлов. (Дополнительные сведения о различных типах политики сборки мусора приведены в статье «Политики сборки мусора, часть 1» в разделе Ресурсы).

Рисунок 7. Использование кучи и время простоя для трех различных политик сборки мусора.
Рисунок 7. Использование кучи и время простоя для трех различных политик сборки мусора.

В данном случае ясно, что режим gencon является наилучшим по всем критериям. При данном режиме задача выполняется быстрее всего, в ходе ее решения используется меньше всего кучи, паузы в сборке мусора также значительно меньше. Но политика gencon не является используемой по умолчанию; по умолчанию используется optthruput, поскольку в большинстве случаев она превосходит gencon. Однако, как показывает данный пример, она не во всех случаях превосходит политику gencon, поэтому стоит испытать работу приложения при различных политиках сборки мусора. Часто очень простое изменение, наподобие смены используемой приложением политики сборки мусора, может вызвать значительное улучшение параметров работы приложения.

Выделение проблемного периода времени

Garbage Collection and Memory Visualizer дает возможность проанализировать в журнале определенный период времени. При выделении определенного периода все данные сводки и рекомендации относятся именно к этому периоду. Например, журнал, показанный на рисунке 8, отображает использование кучи приложением, которое работает днем и простаивает ночью:

Рисунок 8. Использование кучи приложением, работающим днем и простаивающим ночью.
Рисунок 8. Использование кучи приложением, работающим днем и простаивающим ночью.

Для журнала в целом издержки на сборку мусора (т.е. время, потраченное на сборку мусора) составляют около 5 процентов, что весьма неплохо. Однако это время включает длинные периоды бездействия приложения, когда сборка мусора не требуется. Выделение определенного периода дает более точное отражение поведения системы при работе, как показано на рисунке 9:

Рисунок 9. Выделение периода занятости.
Рисунок 9. Выделение периода занятости.

Garbage Collection and Memory Visualizer позволяет также выделить определенный диапазон данных. Например, интерес могут представлять длительные паузы или периоды, в которые размер кучи превышает 500 МБ. Отфильтровать данные подобным образом можно, изменив значения на оси Y.

Изменение единиц измерения

Garbage Collection and Memory Visualizer дает возможность изменить отображаемые единицы измерения. Это повлечет за собой изменение графика, а также изменение единиц измерения в сводной таблице и изменение рекомендаций по настройке.

По умолчанию время (по оси X) измеряется в секундах. Это удобно для коротких отрезков, но не очень удобно для журналов, охватывающих длительные промежутки времени. Для изменения единицы измерения необходимо выбрать соответствующий пункт из выпадающего меню справа, как показано на рисунке 10. Можно выбрать часы, минуты, дату или номер, который является просто номером очередного запуска сборки мусора. Опция Normalize определяет, отображается ли время относительно начала журнала (нормализовано) или в абсолютных значениях (не нормализовано).

Рисунок 10. Изменение единиц измерения.
Рисунок 10. Изменение единиц измерения.

Можно также изменить единицы по оси Y. Например, размер кучи по умолчанию отображается в мегабайтах; это значение можно отобразить в гигабайтах или в процентах от общего размера кучи.

Использование и экспорт шаблонов

Часто одни и те же комбинации полей используются многократно. Garbage Collection and Memory Visualizer дает возможность сохранить эти комбинации для последующего использования в виде шаблона. Вид Templates находится в левом верхнем углу окна, как показано на рисунке 11:

Рисунок 11. Вид Templates.
Рисунок 11. Вид Templates.

Двойной щелчок на шаблоне вызывает применение его к текущему набору данных. Garbage Collection and Memory Visualizer поставляется с некоторыми предопределенными шаблонами. Шаблон Heap (куча) полезен для оценки использования памяти приложением и его требований к памяти. Шаблон Pauses (паузы) используется в качестве первого шага при определении проблем с производительностью, которые могут быть связаны со сборкой мусора.

Можно экспортировать шаблоны, выбрав в меню View или в контекстном меню, появляющемся при щелчке правой клавишей в любом месте вида Templates, пункт Export current settings as template (Экспортировать текущие установки в качестве шаблона). Нужно задать имя шаблона, и Garbage Collection and Memory Visualizer сохранит шаблон в виде Templates для будущего использования.

Изменение цветов

Для изменения цветов, используемых Garbage Collection and Memory Visualizer в графиках, нужно в меню View выбрать пункт Preferences и затем перейти на страницу Display colors в категории Displayers, как показано на рисунке 12:

Рисунок 12. Страница предпочитаемых цветов.
Рисунок 12. Страница предпочитаемых цветов.

Сохранение вывода

Весь вывод Garbage Collection and Memory Visualizer можно сохранить, щелкнув правой кнопкой на основной панели и выбрав из контекстного меню Save, как показано на рисунке 13. График можно сохранить в виде рисунка JPEG, отчет можно сохранить в виде HTML, сырые данные можно сохранить в файле CSV. Диаграммы в данной статье были сохранены из графиков.

Рисунок 13. Сохранение.
Рисунок 13. Сохранение.

Использование рекомендаций

Garbage Collection and Memory Visualizer предоставляет сводку представляющих интерес особенностей подробного журнала сборки мусора с рекомендациями по настройке. Сводка и рекомендации доступны на вкладке Report.

Зачем может понадобиться ручная настройка? Сборщик мусора автоматизирует многие настройки, пытаясь оптимизировать производительность. Однако он ничего не знает о приоритетах и о компромиссах, на которые можно пойти, без соответствующих указаний со стороны программиста. Не существует оптимальной конфигурации для всех режимов работы и во всех условиях. В простейшем случае можно указать сборщику мусора политику и выбрать, что является более приоритетным – производительность или время пауз. При наличии большей склонности к риску или готовности достичь оптимальной производительности можно попытаться настроить размер кучи, изменить размер питомника (nursery) или попытаться увеличить максимальный размер питомника.

Пример: Обнаружение утечки памяти

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

Мягкие и слабые ссылки

Мягкие (soft) ссылки – это такие ссылки, которые можно освободить, если в куче мало свободной памяти. Они полезны для чувствительных к памяти кэшей. Слабые (weak) ссылки – это ссылки, которые будут освобождены, если нет других ссылок на целевой объект. Они незаменимы для карт, связывающих метаданные с объектами, и для поддержания списков обработчиков. Естественно, если элементы в карте должны сохраняться, мягкие ссылки не следует использовать.

Обнаружить утечки памяти обычно довольно просто. Нужно включить режим подробной регистрации сборки мусора, дать приложению немного поработать, а затем (после сборки мусора) отобразить в Garbage Collection and Memory Visualizer диаграмму использования кучи. Использование памяти естественным образом увеличивается при инициализации приложения и при возрастании его загруженности. Если график использования кучи ползет вверх при отсутствии очевидных причин для повышения требований к памяти со стороны приложения, это может свидетельствовать об утечке. Garbage Collection and Memory Visualizer отслеживает этот шаблон и если обнаружит что-либо, напоминающее утечку, добавляет соответствующий комментарий в рекомендации по настройке.

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

Как показано в следующем примере, мощными средствами для исправления утечек памяти являются слабые (weak) и мягкие (soft) ссылки. (Дополнительные сведения о них приведены на врезке, а ссылки на обсуждение того, когда и как их использовать, в разделе Ресурсы). Рассмотрим приложение с явной утечкой, приведенное в листинге 1. Оно добавляет новые элементы в карту, но никогда их не удаляет.

Листинг 1. Класс Java с сильной утечкой памяти.
public class Leaker
{
	private Map things = new HashMap();

	public void leak() {
		while (true) {
			things.put(new Date(), new Leak());
		}
	}

	private class Leak
	{
		private Object data;

		public Leak() {
			data = new Object();
		}
	}
}

На рисунке 14 показано использование памяти данным приложением. Спады в использовании кучи обозначают моменты ее сжатия. Журнал завершается выходом JVM за пределы доступной памяти.

Рисунок 14. Использование кучи приложением с сильной утечкой.
Рисунок 14. Использование кучи приложением с сильной утечкой.

Использование слабых ссылок для избежания утечек

Переключение на WeakHashMap, как показано в листинге 2, сразу же устраняет проблему; работа нового варианта проиллюстрирована на рисунке 15. Использование кучи никогда не превышает 1МБ, и приложение может продолжать работать неопределенно долго.

Листинг 2. Простое исправление класса Leaker, предотвращающее утечку памяти.
	private Map things = new WeakHashMap();
Рисунок 15. Приложение с потенциальной утечкой, исправленное с помощью WeakHashMap.
Рисунок 15. Приложение с потенциальной утечкой, исправленное с помощью WeakHashMap.

Однако для устранения некоторых утечек может оказаться недостаточным даже использование слабых ссылок. Что было бы, если бы карта из рисунка 15 была связанным списком, как показано в листинге 3?

Листинг 3. Дальнейшая модификация класса Leaker, вновь вводящая утечку.
public class Leaker
{
	private Map things = new WeakHashMap();

	public void leak() {
		Object previousThing = null;
		while (true) {
			final Leak thing = new Leak(previousThing);
			things.put(new Date(), thing);
			previousThing = thing;
		}
	}

	private class Leak
	{
		private Object data;

		public Leak(Object thing) {
	   		/* создание связанного списка */
			data = thing;
		}
	}
}

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

Рисунок 16. Использование кучи в приложении с утечкой, когда использование WeakHashMap не может решить проблему
Рисунок 16. Использование кучи в приложении с утечкой, когда использование WeakHashMap не может решить проблему

Обеспечение правильной работы слабых ссылок

Выявить проблему можно на диаграмме освобождаемых Garbage Collection and Memory Visualizer слабых ссылок, как показано на рисунке 17. После добавления связей в список число освобождаемых слабых ссылок падает до нуля. (Новая версия приложения представлена чрезвычайно короткой линией вдоль оси X вблизи нуля, а предыдущая версия – более длинной линией выше). Очевидно, слабые ссылки больше не помогают.

Рисунок 17. Слабые ссылки, освобождаемые в двух вариантах приложения с возможными утечками.
Рисунок 17. Слабые ссылки, освобождаемые в двух вариантах приложения с возможными утечками.

Решением в данном случае является изменение типа ссылок в связанном списке также на слабые. После реализации изменений, приведенных в листинге 4, число освобождаемых слабых ссылок значительно возрастает, а использование кучи вновь становится минимальным:

Листинг 4. Добавление дополнительных слабых ссылок предотвращает сохранение ссылок дольше требуемого времени.
private class Leak
{
	private WeakReference reference;

	public Leak(Object thing) {
		this.reference = new WeakReference(thing);
			/*
	        * объект можно получить обратно по ссылке - 
	        * reference.get(), но обязательно нужно выполнить проверку на null.
	        */
	}
}

Использовав Garbage Collection and Memory Visualizer для проверки количества освобождаемых слабых ссылок, можно легко обнаружить, что перепроектирование с использованием слабых ссылок действительно эффективно.

Если при исследовании кода не удается быстро найти утечку, возможно, придется сделать снимки памяти приложения и проанализировать их, чтобы найти объекты, у которых увеличиваются размеры ссылок. Ссылки на статьи о поиске и исправлении утечек памяти приведены в разделе Ресурсы.

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

Пример: задание размеров кучи

Многие разработчики используют данные подробной регистрации сборки мусора для выбора наилучшего размера кучи. Если куча настолько мала, что требуемые приложению данные не помещаются в нее, приложение израсходует всю доступную память и завершится с OutOfMemoryError. Если у приложения есть место для данных приложения, но нет резерва, сборщик мусора будет вынужден тратить много времени, обеспечивая достаточный размер кучи для новых выделений, и это будет снижать производительность приложения. Слишком большой размер кучи обычно не снижает производительность приложения, но это является расточительством, а перерывы в работе сборщика мусора могут оказаться слишком длительными. Обычно на той же машине работают и другие приложения, поэтому может понадобиться перераспределить память таким образом, чтобы ни у одного Java-приложения не было больше памяти, чем ему нужно.

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

Для размера кучи нет единого идеального размера. Обычно чем больше размер кучи, тем выше производительность приложения, поэтому оценка размера кучи подразумевает сопоставление требований к физической памяти данного приложения с требованиями других приложений. Приемлемая эвристическая оценка - куча должна быть по крайней мере в два раза больше объема реальных данных. Если такой размер кучи невозможен или нежелателен, возможно, лучшей политикой является gencon, поскольку она имеет тенденцию показывать большую по сравнению с политикой optthruput производительность в ситуациях, когда размер кучи ограничен. По возможности следует избегать такого размера кучи, при котором компьютер начинает использовать виртуальную память. Использование виртуальной памяти значительно снижает производительность.

Преимущества фиксированного размера кучи

На рисунке 18 показано время пауз, когда та же рабочая нагрузка, что и на рисунке 7, выполняется на JVM с фиксированным размером кучи в 500 МБ при запуске с опцией командной строки -Xms500m -Xmx500m. На основе данных лишь времени пауз можно было бы сказать, что с фиксированным размером кучи дела пошли хуже. Среднее время пауз для каждой политики увеличилось, а доля времени, затраченного на сборку мусора, не изменилась. Однако, общее время пауз (четвертый столбец в таблицах в виде отчета) на самом деле значительно снизилось. Общее и среднее время пауз отображаются различными, поскольку сборку мусора в небольших кучах можно выполнить очень быстро. При наличии возможности изменения размера кучи JVM выполняла множество очень быстрых сборок при небольшом размере кучи, и это уменьшило среднее время пауз. В этом случае окончательным показателем производительности является время, необходимое JVM для завершения работы (длина линий); фиксирование размера кучи дало 13-процентное улучшение для политики gencon, 15-процентое улучшение для optavgpause и 30-процентное улучшение для optthruput.

Рисунок 18. Время пауз для приложения, запущенного с фиксированным размером кучи.
Рисунок 18. Время пауз для приложения, запущенного с фиксированным размером кучи.

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

Пример: оценка производительности приложения по подробной регистрации сборки мусора

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

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

Как сборка мусора может ускорить выполнение приложения?

Хорошая настройка параметров сборки мусора может повысить производительность приложения. Если объекты расположены компактно, что имеет место в режиме gencon или после уплотнения, выделение новых объектов будет происходить значительно быстрее, поскольку не требуется поиск свободного места. Это не отражается в подробной записи сборки мусора, но быстрое выделение памяти может значительно помочь приложению. При хорошем размещении объектов, когда используемые в одно время объекты находятся рядом друг с другом (это называется локальностью (locality)), доступ к объектам будет значительно быстрее. Толковые сборщики мусора перераспределяют объекты, максимизируя скорость доступа к объектам.

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

Количество собранного мусора можно отобразить на диаграмме, выбрав Amout freed из меню VGC Data Garbage Collection and Memory Visualizer. Диаграмма на вкладке Report отображает статистику о среднем и общем объеме мусора, собранного в ходе работы. Средний объем не является хорошим показателем производительности; при стабильной занятости приложения объем освобождаемой за одну сборку памяти, вероятно, также будет довольно стабильным. Однако при высокой производительности частота сбора, вероятно, возрастет, поскольку приложение выполняет больше работы за меньшее время. Следовательно, общий объем освобожденной памяти является лучшим показателем производительности в течение фиксированного периода времени. Если журнал не был создан для фиксированного периода времени, можно выделить соответствующий период времени и получить общий объем только за этот период.

Еще лучшим показателем является скорость сборки мусора, поскольку по этому показателю можно сравнивать даже записи, не охватывающие один и тот же период времени. Скорость отображается в таблице на вкладке Report вверху. (Если таблицы нет, нужно включить Summary в меню VGC Data). Большая скорость сборки мусора означает, что приложение делает больше работы в течение меньшего времени, что очень хорошо!

Рассмотрим предыдущий пример с фиксированным размером кучи. Среднее время пауз для приложения дает весьма обманчивое впечатление о хорошей сборке мусора. Однако если взглянуть на скорость сборки мусора, можно видеть, что она выше для работы с фиксированной кучей. Например, при сравнении двух запусков в режиме optthruput, показанных на рисунке 19, видно, что скорость выше на 12 процентов, когда размер кучи установлен заблаговременно:

Рисунок 19. Сводка скорости сборки мусора.
Рисунок 19. Сводка скорости сборки мусора.

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

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

Оценка времени ответа приложения

Об этой серии

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

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

С комментариями и вопросами по поводу статей обращайтесь непосредственно к авторам.

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

Заключение

Анализ подробной регистрации сборки мусора часто позволяет лучше понять характеристики работы приложения; при этом можно также обнаружить потенциально серьезные проблемы с использованием памяти и улучшить производительность приложения. Garbage Collection and Memory Visualizer является мощным инструментом для получения максимальной отдачи от информации, получаемой при подробной регистрации сборки мусора.

Ресурсы

Научиться

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

Обсудить

Комментарии

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=343242
ArticleTitle=Диагностика Java в стиле IBM : Часть 2. Сборка мусора с использованием Garbage Collection and Memory Visualizer из инструментария IBM Monitoring and Diagnostic Tools for Java
publish-date=10032008