Продолжая с первой статьи, давайте немного углубимся в аспекты мониторинга производительности любого java-приложения и попробуем понять, как можно осуществлять мониторинг приложения. Определение того, что необходимо отслеживать, программного стека для мониторинга и инструментов, которые можно использовать для мониторинга приложения, очень важно и является первым шагом в этом процессе. Производительность в основном зависит от базовой системы, на которой работает приложение, поэтому может быть очень полезно следить за увеличением использования диска и процессора, прежде чем производительность серьезно пострадает и упадет до неприемлемого уровня. Существуют различные метрики системного уровня, которые следует отслеживать, что может привести к проблемам с общей производительностью. Я постараюсь перечислить здесь некоторые важные из них:
Использование памяти ОС:
Поскольку мы знаем, что выполнение Java-приложения переносит частичное/полное приложение в память, а JVM автоматически запускает сборку мусора для управления памятью, чтобы она не исчерпала память. Использование памяти может напрямую зависеть от запущенного приложения или из-за различных действий по подкачке, подкачке в ОС, переключения контекста и проблем с блокировкой, а также активности миграции потоков. Подкачка в ОС — это концепция, при которой ОС может удалить неиспользуемую страницу данных из памяти и записать страницы данных в часть диска, известную как «пространство подкачки». Это отличный компромисс, когда страница данных не используется, но влечет за собой много циклов процессора, когда на эту страницу данных снова ссылаются и ее необходимо прочитать обратно в память. В частности, при сборке мусора необходимо просмотреть всю кучу на наличие живых объектов и может потребоваться вернуть выгруженные страницы, что может вызвать большую задержку времени сборки мусора. Генерационный сборщик мусора в этом случае работает лучше, так как он пытается реже исследовать старые данные и использует строгую типизацию (GC просматривает данные, потому что ему нужно найти указатели; если он знает, что большой кусок оперативной памяти содержит только не указатели, например, это некоторые данные изображения только со значениями пикселей, тогда он может оставить их в покое и, в частности, не принудительно вернуть их из области подкачки). Существуют различные инструменты командной строки, такие как vmstat, top, которые можно использовать для мониторинга операций подкачки, освобождения памяти и т. д.
Использование ЦП:
Высокая загрузка ЦП в работающей системе указывает на конфликт общих ресурсов или взаимодействие больших устройств ввода-вывода. Использование ЦП может быть связано с выполнением кода системы/ядра, а также выполнением кода приложения. В идеале мы должны уменьшить количество циклов ЦП, затрачиваемых на выполнение системы/ядра, и попытаться увеличить использование ЦП для выполнения кода приложения для повышения производительности. Существуют графические инструменты, такие как gnome-system-monitor, а также инструменты командной строки, такие как top & vmstat, которые могут помочь определить загрузку процессора.
Использование лучшего параллелизма, реструктуризация кода для уменьшения любых проблем с конфликтами блокировок может значительно улучшить загрузку процессора.
Вывод vmstat выглядит так
Использование диска:
Приложения используют базы данных, файлы, ведение журналов и т. д. для некоторых своих основных функций. Активную проверку использования диска на наличие проблем с производительностью следует рассматривать как начальный шаг для понимания производительности приложения. В Linux можно использовать iostat для проверки операций чтения/записи для каждого подключенного диска, а также других интересных показателей. Использование неблокирующего ввода-вывода (инфраструктура NIO) из java, буферизованных потоков, кэширования на стороне приложения и включения кэширования диска может помочь уменьшить эту проблему.
Наряду с указанными выше системными показателями существуют такие вещи, как конфликт блокировок, активность сетевого ввода-вывода, активность миграции потоков, которые можно отслеживать для выявления проблем, связанных с производительностью. такие команды, как pidstat в linux, могут помочь сообщить о переключениях контекста (добровольно и недобровольно), с помощью которых можно рассчитать циклы процессора, потраченные впустую на добровольные переключения контекста.
Добровольное переключение контекста означает, что приложение java может страдать от конфликта блокировок.
Мониторинг производительности представляет собой очень важный шаг в общем анализе производительности приложения, за которым обычно следует деятельность по профилированию производительности. Я надеюсь более подробно рассказать об этих темах в своих будущих статьях на эту тему.
Ресурсы
Следующие статьи можно прочитать, чтобы начать больше изучать анализ и настройку производительности Java.
