Автор оригинала: Ram Lakshmanan.
Непрерывная интеграция/Непрерывное развертывание (CI/CD) стало центральным элементом разработки программного обеспечения. Для обеспечения высококачественных выпусков программного обеспечения в конвейере CI/CD выполняются дымовые тесты, регрессионные тесты, тесты производительности, статический анализ кода и сканирование безопасности. Несмотря на все эти меры качества, в производственной среде по-прежнему возникают ошибки памяти, скачки процессора, невосприимчивость, ухудшение времени отклика.
Такого рода проблемы с производительностью возникают в производстве, потому что в конвейере CI/CD изучаются только показатели макроуровня, такие как: показатели качества статического кода, охват тестом/кодом, загрузка процессора, потребление памяти, время отклика… В некоторых случаях этих макрометрик недостаточно для выявления проблем с производительностью. В этой статье давайте рассмотрим микрометрию, которую следует изучить в конвейере CI/CD, чтобы обеспечить высокое качество выпусков в производстве. Мы также узнаем, как получить эти микрометрические данные и интегрировать их в конвейер CI/CD.
Как прогнозируются цунами? Вы можете задаться вопросом, почему прогнозирование цунами связано с этой статьей. Есть связь . Обычная морская волна движется со скоростью 5-60 миль в час, в то время как волны цунами движутся со скоростью 500-600 миль в час. Даже несмотря на то, что волна цунами движется со скоростью 10-100 – кратной скорости обычных волн, очень трудно предсказать волны цунами. Таким образом, современные технологии используют микрометрию для прогнозирования волн цунами.
Рис.: Дротиковое устройство для обнаружения цунами
To forecast Tsunami, multiple DART (Deep-ocean Assessment and Reporting of Tsunami) devices are installed all throughout the world. This DART contains two parts:
a. Надводный буй: Устройство, которое плавает на поверхности океанской воды b. Монитор морского дна: Устройство, расположенное на дне океана
Глубина глубоководных океанских вод составляет около 6000 метров. ((20-кратная самая высокая башня SalesForce в Сан-Франциско). Всякий раз, когда уровень моря поднимается более чем на 1 мм, DART автоматически обнаруживает это и передает эту информацию на спутник. Это повышение уровня морской воды на 1 мм является ведущим показателем возникновения цунами. Я хотел бы попросить вас остановиться здесь на секунду и визуализировать длину 1 мм в масштабе глубины моря 6000 метров. Это ничего, ничтожно мало. Но этот микрометрический анализ используется для прогнозирования цунами. ** Как прогнозировать цунами производительности с помощью микрометрии? * * Аналогично, существует несколько микрометрических показателей, которые вы можете отслеживать в своем конвейере CI/CD. Эти микрометрические показатели являются ведущими индикаторами нескольких проблем с производительностью, с которыми вы столкнетесь на производстве. Повышение или понижение значений этих микрометрических показателей являются отличными индикаторами возникновения проблем с производительностью.
- Пропускная Способность Сбора Мусора
- Среднее время паузы GC
- Максимальное время паузы GC
- Скорость создания объектов
- Максимальный размер кучи
- Количество нитей
- Состояния потока
- Группы потоков
- Потраченная Впустую Память
- Количество объектов
- Количество классов
Давайте подробно изучим каждую микрометрию:
1. ПРОПУСКНАЯ СПОСОБНОСТЬ СБОРА МУСОРА Сбор мусора в целом-это количество времени, которое ваше приложение тратит на обработку транзакций клиентов, по сравнению с количеством времени, которое ваше приложение тратит на сбор мусора.
Допустим, ваше приложение работает уже 60 минут. За эти 60 минут 2 минуты тратятся на мероприятия GC. Это означает, что приложение потратило 3,33% на деятельность GC (т. е. 2/60 * 100) Это означает, что пропускная способность сбора мусора составляет 96,67% (т. е. 100 – 3,33).
Когда наблюдается снижение пропускной способности GC, это свидетельствует о какой-то проблеме с памятью. Теперь вопрос в следующем: какова допустимая пропускная способность %? Это зависит от приложения и требований бизнеса. Как правило, следует ориентироваться на пропускную способность более 98%.
2. СРЕДНЕЕ ВРЕМЯ ПАУЗЫ ПРИ СБОРКЕ МУСОРА Когда запускается событие сборки мусора, все приложение приостанавливается. Поскольку сборка мусора должна отмечать каждый объект в приложении, посмотрите, ссылаются ли на эти объекты другие объекты, если ссылок нет, то его придется удалить из памяти. Затем фрагментированная память должна быть уплотнена. Для выполнения всех этих операций приложение будет приостановлено. Таким образом, при запуске сборки мусора клиент будет испытывать паузы/задержки. Таким образом, всегда следует стремиться к достижению низкого среднего времени паузы GC.
3. МАКСИМАЛЬНОЕ ВРЕМЯ ПАУЗЫ ПРИ СБОРКЕ МУСОРА Некоторые события по сбору мусора могут занять несколько миллисекунд, в то время как некоторые события по сбору мусора также могут занять от нескольких секунд до нескольких минут. Вы должны измерить максимальное время паузы при сборке мусора, чтобы понять наихудшее возможное воздействие на клиента. Правильная настройка (и, при необходимости, изменения кода приложения) необходимы для сокращения максимального времени паузы при сборке мусора. ** 4. СКОРОСТЬ СОЗДАНИЯ ОБЪЕКТОВ** Скорость создания объектов-это среднее количество объектов, созданных вашим приложением. Возможно, в вашей предыдущей фиксации кода приложение создавало скорость 100 МБ/сек. Начиная с недавней фиксации кода, приложение начало создавать скорость 150 МБ/сек. Эта дополнительная скорость создания объектов может вызвать гораздо большую активность GC, скачки процессора, потенциальную ошибку памяти, утечки памяти, когда приложение работает в течение более длительного периода.
5. МАКСИМАЛЬНЫЙ РАЗМЕР КУЧИ Максимальный размер кучи-это максимальный объем памяти, потребляемой вашим приложением. Если максимальный размер кучи выходит за пределы допустимого, вы должны изучить его. Возможно, в приложении есть потенциальная утечка памяти, недавно введенный код (или 3-е библиотеки/фреймворки) потребляет много памяти, возможно, это законное использование, если это так, вам придется изменить аргументы JVM, чтобы выделить больше памяти.
“Пропускная способность сбора мусора, среднее время паузы GC, максимальное время паузы GC, скорость создания объектов, микрометрические данные пикового размера кучи могут быть получены только из журналов сбора мусора. Никакие другие инструменты не могут быть использованы для этой цели. В рамках вашего конвейера CI/CD вам необходимо запустить набор регрессионных тестов или тест производительности (идеально). Журналы сбора мусора, сгенерированные в ходе теста, должны быть переданы в API REST GCeasy . Этот API анализирует журналы сбора мусора и отвечает с помощью вышеупомянутой микрометрии. Чтобы узнать, куда отправляются эти микрометрические данные в ответе API и выражении пути JSON для них, в этой статье . Если какое-либо значение нарушено, то сборка может завершиться ошибкой. API GC easy REST обладает интеллектом для обнаружения различных других проблем с сборкой мусора, таких как: утечки памяти, время пользователя > sys + в реальном времени, время системы > время пользователя, вызов вызовов API System.gc() ,… О любых обнаруженных проблемах с GC будет сообщено в элементе “проблема” ответа API. Возможно, вам также захочется отслеживать этот элемент”. **
- КОЛИЧЕСТВО НИТЕЙ* * Количество потоков может быть еще одним ключевым показателем для мониторинга. Если количество потоков превысит допустимое, это может вызвать проблемы с процессором и памятью. Слишком много потоков может привести к ” java.lang. Ошибка OutOfMemoryError: не удается создать новый собственный поток в долгосрочной рабочей среде.
7. СОСТОЯНИЯ ПОТОКА Потоки приложений могут находиться в разных состояниях потоков. Чтобы узнать о различных состояниях потока, обратитесь к этому быстрому видеоклипу . Слишком много потоков в работоспособном состоянии может привести к скачку процессора. Слишком большое количество потоков в ЗАБЛОКИРОВАННОМ состоянии может привести к тому, что приложение перестанет отвечать на запросы. Если количество потоков в определенном состоянии потока превышает определенный порог, вы можете рассмотреть возможность создания соответствующих предупреждений/предупреждений в отчете CI/CD.
8. ГРУППЫ ПОТОКОВ Группа потоков представляет собой набор потоков, выполняющих аналогичные задачи. Может существовать группа потоков-контейнеров сервлетов, которая обрабатывает все входящие HTTP-запросы. Может существовать группа потоков JMS, которая обрабатывает все действия по отправке и получению JMS. В приложении также могут быть некоторые другие группы чувствительных потоков. Возможно, вам захочется отслеживать размер этих чувствительных групп потоков. Вы не хотите, чтобы их размер ни опускался ниже порога, ни выходил за его пределы. Меньшее количество потоков в группе потоков может приостановить выполнение действий. Большее количество потоков может привести к проблемам с памятью и процессором.
“Количество потоков, состояния потоков, группы потоков микрометрические данные могут быть получены из дампов потоков. В рамках вашего конвейера CI/CD вам необходимо запустить набор регрессионных тестов или тест производительности (идеально). Во время выполнения тестов следует регистрировать 3 дампы потоков с интервалом в 10 секунд. Захваченные дампы потоков должны быть переданы в API REST быстрого потока . Этот API анализирует дампы потоков и отвечает с помощью вышеупомянутой микрометрии. Чтобы узнать, куда отправляются эти микрометрические данные в ответе API и в выражении пути JSON для них, обратитесь к этой статье . Если какое-либо значение нарушено, то сборка может быть выполнена с ошибкой”. API FastThread REST обладает интеллектом для обнаружения нескольких проблем с потоковой передачей, таких как: взаимоблокировки, потоки с пиковыми нагрузками на процессор, длительные блокирующие потоки, … О любых обнаруженных проблемах будет сообщено в элементе “проблема” ответа API. Возможно, вам также захочется отслеживать этот элемент”.
9. ПОТРАЧЕННАЯ ВПУСТУЮ ПАМЯТЬ В современном вычислительном мире много памяти тратится впустую из-за плохих методов программирования, таких как: создание дубликатов объектов, создание дубликатов строк, неэффективные реализации коллекций, неоптимальные определения типов данных, неэффективные финализации,.. API героя кучи обнаруживает объем памяти, потраченный впустую из-за всех этих неэффективных методов программирования. Это может быть ключевым показателем для отслеживания. В случае, если объем потраченной впустую памяти превышает определенный процент, сборка CI/CD может завершиться ошибкой или могут быть сгенерированы предупреждения.
10. КОЛИЧЕСТВО ОБЪЕКТОВ Вы также можете захотеть отслеживать общее количество объектов, присутствующих в памяти приложения. Количество объектов может резко возрасти из-за неэффективного кода, нового внедрения сторонних библиотек, фреймворков. Слишком большое количество объектов может вызвать ошибку OutOfMemoryError, утечку памяти, скачок производительности процессора.
11. КОЛИЧЕСТВО КЛАССОВ Вы также можете захотеть отслеживать общее количество классов, присутствующих в памяти приложения. Иногда количество классов может резко возрасти из-за внедрения любых сторонних библиотек, фреймворков. Всплеск количества классов может вызвать проблемы в метапространстве/постоянном пространстве памяти.
“Потраченный впустую объем памяти, количество объектов, количество классов микрометрические данные могут быть получены из свалок кучи. В рамках вашего конвейера CI/CD вам необходимо запустить набор регрессионных тестов или тест производительности (идеально). Дампы кучи должны быть захвачены после завершения тестового запуска. Захваченные дампы кучи должны быть переданы в API ОТДЫХА Хизер . Этот API анализирует свалки кучи и отвечает с помощью этой микрометрики. Чтобы узнать, куда отправляются эти микрометрические данные в ответе API и в выражении пути JSON для них, обратитесь к этой статье . Если какое-либо значение нарушено, то сборка может быть выполнена с ошибкой”. API REST героя кучи обладает интеллектом для обнаружения нескольких проблем, связанных с памятью, таких как: утечки памяти, завершение объектов,… О любых обнаруженных проблемах будет сообщено в элементе “проблема” ответа API. Возможно, вам также захочется отслеживать этот элемент”.
Биография автора:
Рам Лакшманан Каждый божий день миллионы и миллионы людей в Северной Америке—банки, путешествия и торговля—используют приложения, разработанные Рамом Лакшмананом. Озу является признанным докладчиком на крупных конференциях по вопросам масштабируемости, доступности и производительности. Недавно он основал стартап, который специализируется на устранении проблем с производительностью .
Оригинал: “https://www.codementor.io/@suryab/micrometics-for-ci-cd-pipeline-pt7ki4h40”