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

Медленная работа Jenkins обычно не имеет одной причины. Интерфейс кажется тяжелым, сборки ждут в очереди, агенты отключаются, логи открываются вечно, и кто-то говорит: «Jenkins снова упал». За этой жалобой часто скрывается одна из нескольких типичных проблем: давление на кучу контроллера, медленный диск, перегруженные агенты, проблемы с плагинами, плохое поведение конвейеров или задержки в сети при обращении к системам контроля версий и артефактов.

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

Память контроллера и сборка мусора

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

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

Сначала проверьте процесс и логи:

ps -o pid,rss,vsz,etime,cmd -C java
journalctl -u jenkins --since "2 hours ago" | grep -Ei 'OutOfMemory|GC overhead|heap|killed'

Для умеренного контроллера кучи размером от 2 до 4 ГБ может быть достаточно. Загруженным установкам может потребоваться больше. Не устанавливайте кучу слепо на большую часть оперативной памяти машины. ОС все еще нужна память для кэша файловой системы, накладных расходов процессов и агентов мониторинга.

Типичные параметры службы выглядят так:

JENKINS_JAVA_OPTS="-Xms1g -Xmx4g -XX:+UseG1GC"

После изменения параметров JVM перезапустите Jenkins в окно технического обслуживания и наблюдайте за поведением при нормальной нагрузке. Если память неуклонно растет в течение нескольких дней и никогда не стабилизируется, сделайте дамп кучи и проверьте недавно обновленные или установленные плагины. Держите плагины актуальными, но избегайте обновления большого набора плагинов без плана отката.

Дисковое пространство и дисковый ввод-вывод

Jenkins постоянно использует диск. JENKINS_HOME хранит конфигурацию заданий, записи сборок, отпечатки, данные плагинов, секреты, логи, а иногда и слишком много артефактов. Агенты используют диск для рабочих областей, кэшей зависимостей, слоев Docker, отчетов о тестировании и временных файлов.

Полный диск очевиден. Медленный диск более раздражает, потому что ничего не выглядит сломанным; все просто ждет.

Проверьте как емкость, так и задержку:

df -h
du -sh /var/lib/jenkins/* 2>/dev/null | sort -h | tail
iostat -xz 1

Если %util и время ожидания высоки во время сборок, диск является узким местом. Распространенные исправления: перемещение рабочих областей на более быстрое хранилище, удаление старых слоев Docker, сокращение срока хранения артефактов и прекращение архивирования заданий целых каталогов, когда нужны только отчеты или пакеты.

Настройте политики удаления сборок для заданий:

options {
  buildDiscarder(logRotator(numToKeepStr: '30', artifactNumToKeepStr: '10'))
}

Будьте осторожны с ручной очисткой в JENKINS_HOME. Не удаляйте случайные XML-файлы или каталоги плагинов, пока Jenkins работает. Используйте настройки хранения Jenkins, инструменты очистки для конкретных плагинов и резервное копирование.

Слишком много работы на контроллере

Одна из самых вредных конфигураций — запуск сборок на контроллере. Контроллер не должен компилировать, запускать тесты, собирать образы Docker или выполнять большие извлечения из репозитория.

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

Также проверьте конвейеры на наличие тяжелого Groovy-кода на контроллере. Шаги конвейера, такие как sh, выполняются на агентах, но логика Groovy в Jenkinsfile может выполняться на контроллере. Избегайте чтения огромных файлов в переменные Groovy, создания массивных карт или выполнения большой обработки JSON в скрипте конвейера. Используйте оболочку, Python, jq или ваш инструмент сборки на агенте для тяжелой работы с данными.

Агенты перегружены или не соответствуют требованиям

Если время ожидания в очереди для одной метки велико, добавление общих исполнителей не поможет. Задание, требующее linux && docker && large-memory, нуждается именно в такой емкости.

Посмотрите на причины очереди и использование меток. Затем проверьте ОС агента:

uptime
free -h
mpstat 1
iostat -xz 1
docker system df

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

Для агентов Kubernetes запросы ресурсов так же важны, как и количество исполнителей Jenkins. Pod, запрашивающий слишком мало ЦП или памяти, может быть запланирован на уже загруженный узел, и тогда Jenkins увидит готового агента, в то время как сборка будет ползти. Для одноразовых pod'ов обычно проще рассуждать об одном исполнителе на pod, чем о нескольких исполнителях, использующих один и тот же контейнер.

Проблемы с плагинами

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

Когда производительность внезапно меняется, спросите, что изменилось недавно:

• Обновление ядра Jenkins.
• Обновление плагина.
• Установка нового плагина.
• Новая глобальная конфигурация.
• Новая версия библиотеки конвейеров.

Используйте информацию о состоянии «Управление Jenkins», логи и журналы изменений плагинов. Если интерфейс стал медленным после обновления плагина, протестируйте откат на тестовом контроллере, если он у вас есть. Делайте резервную копию JENKINS_HOME и версий плагинов перед крупными обновлениями.

Не держите плагины «на всякий случай». Каждый установленный плагин добавляет поверхность для обслуживания. Удалите неиспользуемые плагины после проверки зависимостей заданий.

Задержки в SCM и репозиториях артефактов

Многие сообщения «Jenkins медленный» на самом деле являются проблемами Git, реестра пакетов, реестра контейнеров или репозитория артефактов.

Проверьте логи сборки на наличие повторяющихся медленных шагов:

git fetch
mvn dependency:resolve
npm ci
docker pull
docker push
archiveArtifacts

Если каждое задание ждет загрузки зависимостей, добавьте прокси или кэш поблизости. Если git fetch медленный, проверьте размер репозитория, обнаружение веток, настройки поверхностного клонирования и сетевой путь от агентов к Git-серверу. Если Docker pull'ы медленные на эфемерных агентах, используйте зеркало реестра или кэш реестра BuildKit.

Будьте честны в диагностике: Jenkins планирует работу, но он не может ускорить удаленный реестр пакетов.

Раздувание логов и истории сборок

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

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

Затем настройте хранение:

options {
  buildDiscarder(logRotator(daysToKeepStr: '30', numToKeepStr: '50'))
}

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

Практический сценарий инцидента

Когда Jenkins медленный прямо сейчас, используйте этот порядок:

1. Проверьте, медленный ли интерфейс контроллера.
2. Проверьте ЦП, память, симптомы GC и диск контроллера.
3. Проверьте причины очереди и какие метки ожидают.
4. Проверьте самые загруженные агенты на ЦП, память, диск и рост рабочей области.
5. Сравните недавние изменения плагинов, заданий и общих библиотек.
6. Прочитайте один медленный лог сборки и определите повторяющийся дорогой шаг.

Этот путь предотвращает случайную настройку. Увеличение кучи не исправит насыщенный Docker-агент. Добавление исполнителей не исправит полный диск. Очистка рабочих областей не исправит плагин, вызывающий паузы контроллера.

Поддерживайте Jenkins в работоспособном состоянии

У здоровых установок Jenkins есть скучные привычки: исполнители контроллера установлены на ноль, агенты настроены под свою рабочую нагрузку, настроено хранение сборок, кэши зависимостей продуманы, обновления плагинов отслеживаются, а основные метрики экспортируются в Prometheus, Grafana, CloudWatch или любую другую систему мониторинга, которую использует команда.

Лучшее исправление часто бывает маленьким и конкретным. Перенесите Docker-сборки на выделенные агенты. Сократите вывод логов шумного задания. Добавьте прокси Maven. Уменьшите количество исполнителей на узле со свопингом. Удалите неиспользуемый плагин. Настройте хранение для задания, которое хранило каждую сборку годами.

Производительность Jenkins улучшается, когда вы перестаете относиться к нему как к одному черному ящику и начинаете следить за работой: от очереди к контроллеру, от контроллера к агенту, от агента к файловой системе, от файловой системы к сетевой зависимости и обратно к логу сборки.

Пример: сборка медленная, но Jenkins в порядке

Предположим, разработчики сообщают, что проверки pull request занимают 25 минут. Интерфейс Jenkins отзывчив. Очередь короткая. Агенты онлайн. Медленный лог показывает:

git fetch: 20 секунд
npm ci: 9 минут
unit tests: 4 минуты
docker build: 10 минут
archive artifacts: 1 минута

Это не проблема контроллера Jenkins. Вероятные исправления: кэширование пакетов, порядок слоев Dockerfile, кэш BuildKit и, возможно, разделение тестов. Увеличение кучи контроллера ничего не изменит.

Пример: все ждет, но агенты простаивают

Если задания стоят в очереди, а агенты кажутся простаивающими, прочитайте причину очереди. Вы можете обнаружить, что задания требуют linux && docker, в то время как у простаивающих агентов есть только linux. Или задания могут быть заблокированы disableConcurrentBuilds, блокируемым ресурсом или облачным плагином, который не может предоставить соответствующих агентов.

Такое узкое место — это конфигурация, а не нехватка ресурсов. Добавление двух неподходящих агентов не поможет.

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

Если интерфейс деградирует в одно и то же время каждый день, ищите запланированные задания: индексация веток, резервное копирование, очистка больших артефактов, сканирование уязвимостей или ночные конвейеры, запускающиеся слишком рано. Проверьте ЦП, кучу и дисковый ввод-вывод контроллера в это окно. Также проверьте, не запускаются ли многие задания в одну и ту же минуту из-за cron-выражений, таких как 0 2 * * *.

В расписаниях Jenkins отдавайте предпочтение хэшированному времени, где это возможно:

H 2 * * *

Это распределяет задания, а не запускает все в начале часа.

Что должен отвечать хороший мониторинг

Как минимум, мониторинг должен отвечать на эти вопросы без входа на сервер:

• Жив ли процесс контроллера и отвечает ли он?
• Сколько кучи используется и как часто выполняется сборка мусора?
• Как долго задания ждут в очереди по меткам?
• Какие агенты отключены или постоянно переподключаются?
• Не заполнены ли диски контроллера и агентов?
• Становятся ли сборки медленнее со временем для одних и тех же заданий?

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