Микрометрика для конвейера CI/CD |

Начните писать здесь… Непрерывная интеграция/непрерывное развертывание (CI/CD) стали центральным элементом разработки программного обеспечения. Для обеспечения выпуска высококачественного программного обеспечения в конвейере CI/CD выполняются дымовые тесты, регрессионные тесты, тесты производительности, статический анализ кода и проверки безопасности. Несмотря на все эти меры качества, в производственной среде по-прежнему возникают ошибки OutOfMemoryError, всплески загрузки ЦП, зависание, снижение времени отклика.

Такого рода проблемы с производительностью возникают в производственной среде, потому что в конвейере CI/CD изучаются только метрики макроуровня, такие как: метрики качества статического кода, покрытие тестами/кодом, использование ЦП, потребление памяти, время отклика…. В некоторых случаях этих макрометрик недостаточно для выявления проблем с производительностью. В этой статье давайте рассмотрим микрометрики, которые следует изучать в конвейере CI/CD для выпуска высококачественных релизов в продакшн. Мы также узнаем, как получать эти микрометрики и интегрировать их в конвейер CI/CD.

Как прогнозируют цунами?
Вы можете задаться вопросом, почему прогнозирование цунами связано с этой статьей. Есть отношения . Обычная морская волна распространяется со скоростью 5–60 миль в час, тогда как волны цунами распространяются со скоростью 500–600 миль в час. Несмотря на то, что волна цунами распространяется со скоростью, в 10-100 раз превышающей скорость обычных волн, предсказать волны цунами очень сложно. Таким образом, современные технологии используют микрометрику для прогнозирования волн цунами.

Рис. Устройство DART для обнаружения цунами.

             To forecast Tsunami, multiple DART (Deep-ocean Assessment and Reporting of Tsunami) devices are installed all throughout the world. This DART contains two parts:

а. Поверхностный буй: устройство, плавающее на поверхности океанской воды.
б. Монитор морского дна: устройство, размещенное на дне океана.

Глубокие воды океана составляют около 6000 метров в глубину. (в 20 раз выше самой высокой башни отдела продаж в Сан-Франциско). Всякий раз, когда уровень моря поднимается более чем на 1 мм, DART автоматически определяет это и передает эту информацию на спутник. Это повышение уровня морской воды на 1 мм является главным индикатором возникновения цунами. Я хотел бы попросить вас остановиться здесь на секунду и визуализировать длину 1 мм в масштабе 6000 метров глубины моря. Это ничего, ничтожно мало. Но этот микрометрический анализ используется для прогнозирования цунами.

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

1. Пропускная способность сборки мусора
2. Среднее время паузы GC
3. Максимальное время паузы GC
4. Скорость создания объекта
5. Максимальный размер кучи
6. Число потоков
7. Состояния потока
8. Группы тем
9. Потерянная память
10. Количество объектов
11. Количество классов

Изучим каждую микрометрику подробно:

1. ПРОИЗВОДИТЕЛЬНОСТЬ СБОРА МУСОРА
Сбор мусора — это количество времени, которое ваше приложение тратит на обработку транзакций клиентов, по сравнению с количеством времени, которое ваше приложение тратит на сборку мусора.

Допустим, ваше приложение работает уже 60 минут. В этих 60 минутах 2 минуты тратятся на действия GC.
Это означает, что приложение потратило 3,33% на действия GC (т.е. 2/60 * 100).
Это означает, что пропускная способность сборки мусора составляет 96,67% (т.е. 100 – 3,33).

Снижение пропускной способности сборщика мусора указывает на какую-то проблему с памятью. Теперь вопрос: какова приемлемая пропускная способность? Это зависит от приложения и бизнес-требований. Как правило, следует ориентироваться на пропускную способность более 98%.

2. СРЕДНЕЕ ВРЕМЯ ПАУЗЫ НА ВЫБОР МУСОРА
Когда запускается событие сборки мусора, все приложение приостанавливается. Поскольку сборщик мусора должен пометить каждый объект в приложении, посмотреть, ссылаются ли на эти объекты другие объекты, если ссылок нет, то его придется вытеснить из памяти. Затем фрагментированная память должна быть уплотнена. Для выполнения всех этих операций приложение будет приостановлено. Таким образом, когда выполняется сборка мусора, клиент будет испытывать паузы/задержки. Таким образом, всегда следует стремиться к достижению низкого среднего времени паузы GC.

3. МАКСИМАЛЬНОЕ ВРЕМЯ ПАУЗЫ ДЛЯ СБОРА МУСОРА
Некоторые события сборки мусора могут занимать несколько миллисекунд, тогда как некоторые события сборки мусора также могут занимать от нескольких секунд до нескольких минут. Вы должны измерить максимальное время приостановки сборки мусора, чтобы понять, каковы наихудшие возможные последствия для клиента. Правильная настройка (и, при необходимости, изменение кода приложения) необходима для сокращения максимального времени паузы сборки мусора.

4. СКОРОСТЬ СОЗДАНИЯ ОБЪЕКТОВ
Скорость создания объектов — это среднее количество объектов, созданных вашим приложением. Возможно, в вашей предыдущей фиксации кода приложение создавало 100 МБ/с. Начиная с последней фиксации кода, приложение начало создавать 150 МБ/сек. Эта дополнительная скорость создания объектов может вызвать гораздо большую активность GC, всплески ЦП, потенциальную ошибку OutOfMemoryError, утечки памяти, когда приложение работает в течение более длительного периода.

5. ПИКОВЫЙ РАЗМЕР КУЧИ
Пиковый размер кучи — это максимальный объем памяти, потребляемый вашим приложением. Если пиковый размер кучи выходит за пределы допустимого, вы должны исследовать это. Возможно, в приложении есть потенциальная утечка памяти, недавно введенный код (или третьи библиотеки/фреймворки) потребляет много памяти, возможно, его законное использование, в этом случае вам придется изменить свои аргументы JVM, чтобы выделить больше Память.

«Пропускная способность сборки мусора, среднее время паузы GC, максимальное время паузы GC, скорость создания объектов, микрометрические данные о пиковом размере кучи можно получить только из журналов сборки мусора. Никакие другие инструменты не могут быть использованы для этой цели.
В рамках конвейера CI/CD вам необходимо выполнить набор регрессионных тестов или тест производительности (в идеале). Журналы сборки мусора, сгенерированные в результате теста, должны быть переданы в REST API GCeasy. Этот API анализирует журналы сборки мусора и отвечает вышеупомянутыми микрометриками. Чтобы узнать, куда отправляются эти микрометрики в ответе API и выражении пути JSON для них, к этой статье. Если какое-либо значение нарушено, сборка может завершиться ошибкой. GCeasy REST API обладает интеллектом для обнаружения различных других проблем со сборкой мусора, таких как: утечка памяти, время пользователя> sys + реальное время, время sys> время пользователя, вызов вызовов API System.gc(),… О любых обнаруженных проблемах GC будет сообщено в элементе «проблема» ответа API. Возможно, вы захотите отслеживать и этот элемент».

6. ЧИСЛО ПОТОКОВ*
   Количество потоков может быть еще одним ключевым показателем для мониторинга. Если количество потоков превышает лимит, это может вызвать проблемы с процессором и памятью. Слишком много потоков может вызвать ошибку java.lang.OutOfMemoryError: невозможно создать новый собственный поток в долго работающей производственной среде.

7. СОСТОЯНИЯ ПОТОКА
Потоки приложения могут находиться в разных состояниях. Чтобы узнать о различных состояниях потока, обратитесь к этому короткому видеоклипу. Слишком много потоков в состоянии RUNNABLE может вызвать всплеск загрузки ЦП. Слишком много потоков в состоянии BLOCKED может привести к тому, что приложение не будет отвечать на запросы. Если количество потоков в определенном состоянии потока превышает определенный порог, вы можете рассмотреть возможность создания соответствующих предупреждений/предупреждений в отчете CI/CD.

8. ГРУППЫ РЕЗЬБЫ
Группа потоков представляет собой набор потоков, выполняющих аналогичные задачи. Может существовать группа потоков контейнера сервлетов, которая обрабатывает все входящие HTTP-запросы. Может быть группа потоков JMS, которая обрабатывает все операции отправки и получения JMS. В приложении могут быть и другие конфиденциальные группы потоков. Возможно, вы захотите отслеживать размер этих групп конфиденциальных потоков. Вы не хотите, чтобы их размер ни опускался ниже порога, ни превышал порог. Меньшее количество потоков в группе потоков может привести к остановке действий. Большее количество потоков может привести к проблемам с памятью и процессором.

«Счетчик потоков, состояния потоков, микрометрики групп потоков можно получить из дампов потоков. В рамках конвейера CI/CD вам необходимо выполнить набор регрессионных тестов или тест производительности (в идеале). 3 Дампы потоков с интервалом в 10 секунд должны быть захвачены во время выполнения тестов. Захваченные дампы потоков должны быть переданы в REST API FastThread. Этот API анализирует дампы потоков и отвечает вышеупомянутыми микрометриками.
Чтобы узнать, куда отправляются эти микрометрики в ответе API и выражении пути JSON для них, см. к этой статье. Если какое-либо значение нарушено, сборка может завершиться ошибкой». FastThread REST API обладает интеллектом для обнаружения нескольких проблем с потоками, таких как: тупиковые блокировки, пиковые потоки ЦП, длительные потоки блокировки и т. д. О любых обнаруженных проблемах будет сообщено в элементе «проблема» ответа API. Возможно, вы захотите отслеживать и этот элемент».

9. ПОТЕРЯННАЯ ПАМЯТЬ
В современном вычислительном мире много памяти тратится впустую из-за неправильных методов программирования, таких как: создание повторяющихся объектов, создание повторяющихся строк, неэффективные реализации коллекций, неоптимальные определения типов данных, неэффективные финализации,… API героев кучи обнаруживает объем памяти, потраченный впустую из-за всех этих неэффективных методов программирования. Это может быть ключевым показателем для отслеживания. В случае, если объем потерянной памяти превышает определенный процент, сборка CI/CD может завершиться ошибкой или могут быть сгенерированы предупреждения.

10. СЧЕТЧИК ОБЪЕКТОВ
Вы также можете отслеживать общее количество объектов, присутствующих в памяти приложения. Количество объектов может резко возрасти из-за неэффективного кода, нового внедрения сторонних библиотек, фреймворков. Слишком большое количество объектов может вызвать ошибку OutOfMemoryError, утечку памяти, всплеск производительности ЦП.

11. ПОДСЧЕТ КЛАССОВ
Вы также можете отслеживать общее количество классов, присутствующих в памяти приложения. Иногда количество классов может увеличиваться из-за внедрения каких-либо сторонних библиотек, фреймворков. Всплеск количества классов может вызвать проблемы в пространстве памяти Metaspace/PermGen.

«Размер потраченной впустую памяти, количество объектов, микрометрические показатели количества классов могут быть получены из дампов кучи. В рамках конвейера CI/CD вам необходимо запустить набор регрессионных тестов или тест производительности (в идеале). Дампы кучи должны быть захвачены после завершения тестового прогона. Захваченные дампы кучи следует передавать в RESTAPI HeapHero. Этот API анализирует дампы кучи и возвращает эти микрометрики.
Чтобы узнать, куда отправляются эти микрометрики в ответе API и выражении пути JSON для них, обратитесь к этой статье. Если какое-либо значение нарушено, сборка может завершиться ошибкой». HeapHero REST API обладает интеллектом для обнаружения нескольких проблем, связанных с памятью, таких как: утечки памяти, финализация объектов и т. д. О любых обнаруженных проблемах будет сообщено в элементе «проблема» ответа API. Возможно, вы захотите отслеживать и этот элемент».