Добрый день. Как я уже понял, начал я слишком издалека, - все-таки стоит сразу рассказать про рабочие инструменты анализа и решения проблем производительности, а определения давать "по ходу дела". Так и поступим.
Проблемы производительности могут возникать и исчезать, они могут быть связаны с одной из подсистем программно-аппаратного комплекса, а могут затрагивать сразу несколько, тем самым резко усложняя процесс поиска и устранения причины замедления системы. Способность быстро выявлять факторы проблемы означает, что мы можем быстрее реагировать на них, что, в свою очередь, приводит к сокращению времени простоя или времени наличия проблемы. Было бы заманчиво обзавестись максимально универсальной методикой или отдельным методом поиска проблем производительности в различных подсистемах, тем самым максимально унифицируя и упрощая процесс устранения проблемы.
Одним из подобных методов является U.S.E. (или USE): Utilization Saturation and Errors method, который был предложен Бренданом Греггом (Brendan Gregg), ведущим аналитиком производительности систем из компании Netflix. Более подробно о методе U.S.E. можно узнать на его сайте: https://www.brendangregg.com/usemethod.html а мы пока рассмотрим USE как практический вариант, который можно применить в повседневной работе.
Метод USE в первом приближении может быть рассмотрен как простой чек-лист на случай возникновения чрезвычайной ситуации для всех критических ресурсов вашей системы: для каждого ресурса вашей системы проверьте наличие одного или нескольких элементов из списка:
Использование/загрузка (UTILIZATION): среднее время, в течение которого ресурс был в работе или в обслуживании других систем. Обычно мы представляем использование в процентах за определенное время, например CPU, диски, и т.д.
Насыщение (SATURATION): объем работы, который ресурс не может обслужить. Обычно мы представляем эту метрику как длину очереди.
Ошибки (ERRORS): наличие ошибок любого рода, связанных с ресурсом и способных влиять на производительность: сбойные сектора на диске, ошибки сетевых протоколов и т.д.
Давайте определимся с понятием ресурса - это любой функциональный компонент вашей системы: сетевые соединения и процессоры, диски, память и прочее. Потенциально ресурс может быть исчерпан либо заблокирован и тем самым может быть спровоцирована ситуация "бутылочного горлышка" (bottleneck) или же вообще ошибки (error). При этом не исключается, что ресурс может быть вообще программным. Программные ресурсы мы рассматривать пока не будем, поэтому сосредоточимся на аппаратных ресурсах.
Важно помнить, что использование/загрузка и насыщение — это показатели зависящие от времени, поэтому поиск оптимального интервала наблюдения для их корректного определения может потребовать тестов и некоторого исследования с помощью некоторой системы мониторинга. Так, в ходе тестов системы мониторинга любого рода стоит предусмотреть ситуацию, когда всплеск использования либо загрузки ресурса может вызвать проблемы с насыщением и производительностью, хотя на значительном промежутке времени использование либо загрузка ресурса может быть в среднем небольшим. Сокращение же временного интервала может выявить всплески (burst) использования либо загрузки ресурса.
Начать использовать метод USE достаточно просто:
Создайте контрольный список ресурсов. Подумайте обо всех различных ресурсах, которые использует ваша система, и о том, как вы хотите их измерить. Некоторые ресурсы способны вызывать проблемы с производительностью более чем одним способом: например, сетевое соединение может вызывать проблемы с I/O, а также проблемы с производительностью CPU. Удостоверьтесь, что создали отдельный элемент мониторинга для каждого типа проблемы, чтобы сделать процесс идентификации более полным и быстрым.
Метод USE лучше всего работает с ресурсами, производительность которых снижается при интенсивном использовании. Он плохо работает с ресурсами, использующими кэширование, поскольку кэширование повышает производительность ресурсов при интенсивном использовании.
В дополнении, часто упускается из виду, что CPU, память и ввод-вывод (I/O) связаны между собой, однако проблемы производительности в этом моменте достаточно редки. С другой стороны, если это все-таки так, то у вас крупные проблемы с аппаратной либо программно-аппаратной частью системы и стоит задуматься об обновлении либо оптимизации "железа" системы. В любом случае, метод USE подскажет вам в этом случае то, что проблемы с ресурсами в иных подсистемах отсутствуют и стоит повнимательнее отнестись к производительности соединений компонентов.
Построение системы мониторинга. На этом этапе необходимо в выбранной системе мониторинга создать метрики, учитывая список ресурсов и типы метрик. Для каждого ресурса стоит предусмотреть надежный способ сбора метрик каждого типа (загрузка/насыщение/ошибки), их обработку и своевременное уведомление системы или пользователя об отклонениях от заданных значений. Например для системы хранения данных имеет смысл анализировать ошибки устройства (errors: hard/soft), насыщение (длина очереди ожидания, wait queue length), использование либо загрузку (device busy, %).
Удостоверьтесь в том, что правильно интерпретируете получаемые показатели. Для некоторых показателей интерпретация может быть очевидной, для других - показатели могут зависить от нагрузки или наличия/отсутствия очередей. Общие рекомендации, которые приводит автор метода, следующие:
- Использование/загрузка ресурса: максимальная загрузка ресурса обычно является признаком проблемы. Чрезмерная загрузка (например, более 70%) может стать проблемой по нескольким причинам: когда загрузка ресурса измеряется в течение относительно длительного периода времени (несколько секунд или минут), общая загрузка, скажем, 70 % может скрыть короткие всплески 100 % загрузки.
Некоторые системные ресурсы, такие как жесткие диски, не могут быть прерваны во время операции даже для работы с более высоким приоритетом. Когда их загрузка превышает 70%, задержки в очереди могут стать более частыми и заметными. С другой стороны, CPU могут быть прерваны («разгружены») практически в любой момент.
- Насыщенность: любая ненулевая степень насыщенности может быть проблемой. Это может быть измерено как длина очереди ожидания или время ожидания в очереди.
- Ошибки: заслуживают изучения ненулевые счетчики ошибок, особенно если они продолжают увеличиваться при сохраняющейся низкой производительности.
Уже добавлю от себя: согласуйте предельные параметры с имеющимся в комании или у клиента SLA. В вашей компании может иметься действующий SLA, который может описывать доступность некоторых систем. Добавляя в систему мониторинга метрики и устанавливая предельные значения срабатывания (например предустановки триггеров в Zabbix) имеет смысл удостовериться, что вы не выходите за пределы действующего SLA и проблема не успеет развиться до такого состояния, при котором может произойти нарушение соглашения.
И тоже от себя: настроив систему мониторинга сразу настраивайте весь спектр требуемых оповещений и уведомлений, включая информационные панели и мнемосхемы. Рекомендую поначалу тестировать систему мониторинга и особенно уведомлений "на кошках", то есть на группе коллег, которые не будут впадать в панику при каждом оповещении об уровне загрузки CPU в 100%. Затем планомерно и вдумчиво настраивайте систему на оптимальный уровень срабатывания уведомлений и контроля данных. Цель всех действий состоит в том, чтобы выявлять проблемы на ранней стадии и решать их до того, как они повлияют на пользователей или производительность системы.
У автора метода можно найти неплохую таблицу для контроля производительности различных ОС, находится она тут: https://www.brendangregg.com/USEmethod/use-rosetta.html Отнеситесь к ней как к руководству, но не как к единственно верному способу контроля требуемых параметров.
В заключении стоит сказать, что метод USE действительно работает как базовый метод для быстрого развертывания мониторинга производительности и дает отличные результаты.
Если будут какие-либо пожелания или вопросы - добро пожаловать в комментарии.
