Устранение медленных сборок Jenkins: распространенные узкие места и решения

Медленные сборки Jenkins вредят, потому что задерживают обратную связь. Разработчик отправляет небольшое изменение, ждет двадцать минут, а затем узнает, что тест провалился в первую минуту. Прежде чем что-либо настраивать, разделите время ожидания в очереди, время запуска агента, время checkout, настройку зависимостей, время тестирования, упаковку и развертывание. Это разные проблемы с разными решениями.

Цель не в том, чтобы сделать Jenkins быстрее на панели управления. Цель — чтобы следующий полезный сигнал поступил раньше.

1. Первичная диагностика: куда уходит время?

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

Анализ лога сборки

Самый непосредственный ресурс — это вывод консоли для медленной сборки. Ищите большие разрывы во временных метках между последовательными шагами.

• Определите длительные шаги: Отметьте, какие шаги сборки (например, mvn clean install, выполнение скрипта, загрузка зависимостей) потребляют больше всего времени.
• Внешние вызовы: Обратите внимание на этапы, связанные с сетевой активностью (например, получение внешних зависимостей, подключение к удаленным репозиториям артефактов). Часто это внешние зависимости, а не сам Jenkins.

Использование графика времени сборки

Jenkins Blue Ocean или классические пайплайны в пользовательском интерфейсе часто отображают визуальную разбивку продолжительности этапов. Используйте эту визуальную подсказку, чтобы подтвердить, какие этапы непропорционально длинны.

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

2. Узкие места инфраструктуры Jenkins

Если сами шаги сборки выполняются быстро, но время ожидания между заданиями велико, проблема, скорее всего, в инфраструктуре контроллера (мастера) или агента (слейва) Jenkins.

Доступность исполнителей и перегрузка

Самая распространенная проблема инфраструктуры — недостаточная мощность для сборок.

Понимание исполнителей

Исполнители — это параллельные слоты, доступные на узле Jenkins для выполнения заданий. Если у узла 5 исполнителей, он может выполнять 5 заданий одновременно.

• Симптом: Сборки постоянно стоят в очереди, даже при низкой загрузке ЦП/памяти.
• Решение: Увеличьте количество исполнителей на ваших основных узлах сборки или добавьте больше узлов/агентов в ваш парк.

Проверка конфигурации (Управление агентами): Проверьте экран конфигурации агента. Убедитесь, что «Количество исполнителей» установлено в соответствии с оборудованием, выделенным для этого агента.

Загрузка контроллера

Если узел контроллера Jenkins испытывает трудности, он не может правильно планировать задания, даже если агенты свободны.

• Симптомы: Медленная реакция пользовательского интерфейса, задержки в планировании сборок, высокая загрузка ЦП/памяти, о которой сообщает системный монитор контроллера.
• Решение: Перенесите ресурсоемкие задачи (например, компиляцию) на агентов. Убедитесь, что у контроллера достаточно ресурсов (ЦП, достаточный объем ОЗУ), выделенных в первую очередь для задач управления, а не для сборки.

Производительность дискового ввода-вывода

Медленный дисковый ввод-вывод (I/O) влияет на шаги, связанные с операциями с большими файлами, такие как клонирование Git-репозиториев или распаковка больших архивов.

• Лучшая практика: Используйте быстрые накопители (SSD или сетевое хранилище с высокой пропускной способностью) для рабочих областей Jenkins и домашнего каталога Jenkins, особенно на агентах сборки.

3. Оптимизация скриптов пайплайнов

Неэффективные декларативные или скриптовые пайплайны могут создавать ненужные накладные расходы.

Управление рабочей областью

Большие рабочие области, заполненные старыми артефактами, могут замедлить последующие операции, такие как клонирование или очистка.

• Используйте шаг ws() с умом: Если вы используете Scripted Pipeline, помните об операциях над всей рабочей областью.
• Очистка рабочей области: Настройте задания на очистку рабочей области после успешного завершения или используйте шаг cleanWs() с умом. Предупреждение: Не очищайте рабочие области, если вы полагаетесь на инкрементальные сборки или кэширование артефактов между запусками.

Избыточные операции (загрузка зависимостей)

Повторная загрузка одних и тех же зависимостей тратит время впустую.

• Кэширование зависимостей: Реализуйте стратегии кэширования, специфичные для инструментов сборки, в среде агента (например, локальный репозиторий Maven, кэш npm). Убедитесь, что каталог кэша является постоянным и, если возможно, общим.

// Пример: Обеспечение постоянства репозитория Maven на агенте
steps {
    sh 'mvn -B clean install -Dmaven.repo.local=/path/to/shared/maven/cache'
}

Параллелизация независимых этапов

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

pipeline {
    agent any
    stages {
        stage('Build & Test') {
            parallel {
                stage('Unit Tests') {
                    steps { sh './run_tests.sh' }
                }
                stage('Static Analysis') {
                    steps { sh './run_sonar.sh' }
                }
            }
        }
        stage('Package') {
            // Выполняется после завершения обоих этапов Build & Test
            steps { sh './create_jar.sh' }
        }
    }
}

4. Использование механизмов кэширования сборок

Для сборок, которые повторно используют большие компоненты (например, Docker-образы или скомпилированные исходные файлы), кэширование имеет решающее значение для скорости.

Кэширование слоев Docker

Если ваш пайплайн собирает Docker-образы, эффективно используйте кэширование слоев.

1. Порядок имеет значение: Размещайте шаги, которые часто меняются (например, COPY . .), позже в Dockerfile, чем шаги, которые меняются редко (например, установка базовых зависимостей).
2. Используйте Docker-агент: При использовании агентов Jenkins, работающих в Docker, убедитесь, что процесс сборки использует существующие локальные кэши образов перед попыткой полной загрузки/сборки.

Инкрементальные сборки

Убедитесь, что ваши инструменты сборки настроены на инкрементальные сборки, где это применимо (например, кэш сборки Gradle или использование определенных флагов компилятора).

5. Конфигурация агента и распределение ресурсов

Агенты — это место, где выполняется основная работа. Убедитесь, что они правильно подготовлены и настроены.

Аппаратное обеспечение

Если загрузка ЦП высока во время сборок, агенту требуется больше вычислительной мощности. Если сборки часто ожидают ресурсы (например, память), увеличьте объем ОЗУ.

Метод запуска агента

• Статические агенты: Более быстрый запуск, но менее гибкие для масштабирования.
• Динамические агенты (например, агенты Kubernetes или EC2): Хотя настройка занимает немного больше времени, эти агенты гарантируют, что ресурсы масштабируются именно тогда, когда это необходимо, избегая длинных очередей в пиковое время.

Лучшая практика: Для динамического масштабирования убедитесь, что время запуска нового агента значительно меньше, чем время, через которое задание истекает в очереди. Если подготовка агента занимает 10 минут, а задания ждут только 3 минуты, масштабирование не поможет устранить непосредственное узкое место.

Практическое руководство по медленным сборкам

1. Анализируйте логи: Определите, какой шаг пайплайна потребляет больше всего времени.
2. Проверьте исполнителей: Убедитесь, что количество исполнителей агента соответствует ожидаемой параллельной нагрузке.
3. Оптимизируйте ввод-вывод: Убедитесь, что рабочие области и кэши находятся на быстром хранилище.
4. Кэшируйте зависимости: Реализуйте постоянство для кэшей Maven, npm или других зависимостей.
5. Параллелизируйте: Перепишите независимые этапы пайплайна для одновременного выполнения.
6. Профилируйте инструменты: Убедитесь, что инструменты сборки (Maven, Gradle) используют функции инкрементальной сборки.

Систематически устраняя эти потенциальные узкие места — от мощности инфраструктуры до эффективности скриптов — вы можете превратить медленные, раздражающие сборки в быстрые и надежные компоненты вашего CI/CD рабочего процесса.

Более честный способ чтения медленной сборки

Самый быстрый способ потратить время впустую — рассматривать каждую медленную сборку Jenkins как проблему Jenkins. Иногда Jenkins является узким местом. Часто он просто передает сообщение. Пайплайн может выглядеть медленным, потому что он ждет в очереди, потому что агенту требуется много времени для запуска, потому что Git checkout затягивается, потому что инструмент сборки снова загружает весь интернет, потому что тесты сериализованы или потому что этап развертывания ожидает другую систему.

Когда я смотрю на медленное задание, я разделяю общее время на четыре категории: время в очереди, время подготовки агента, время настройки рабочей области и фактическое время сборки/тестирования. Jenkins показывает часть этого на странице сборки и в представлении этапов пайплайна, но лог консоли по-прежнему является наиболее полезной записью. Добавьте временные метки, если они отсутствуют. Затем сравните медленный запуск с нормальным. Вы ищете первое место, где две временные линии расходятся.

Например, если медленный запуск тратит восемь минут до начала первой команды оболочки, настройка Maven не поможет. Проверьте доступность исполнителей, соответствие меток, подготовку облачных агентов и ожидающие задания. Если медленный запуск начинается быстро, но тратит пять минут на git fetch, посмотрите на размер репозитория, refspecs, теги, сетевой путь и повторное использование рабочей области. Если checkout быстрый, но npm ci каждый раз медленный, проверьте постоянство кэша и доступ к реестру с агента.

Не оптимизируйте по памяти. Выберите три последние сборки: одну быструю, одну типичную и одну медленную. Запишите продолжительность каждого этапа. Эта небольшая таблица обычно указывает на правильный слой.

Время в очереди: узкое место до начала сборки

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

Начните со страницы задания и панели состояния исполнителей. Если много агентов простаивают, но задание стоит в очереди, выражение метки может быть слишком строгим. Задание с меткой linux && docker && java17 && large может выполняться только на узлах, соответствующих всем меткам. Это может быть намеренно для сборки релиза, но часто случайно для обычных проверок pull request. Если для обычной сборки нужны только Docker и Java, не привязывайте ее к одной специальной машине, если нет реальной причины.

Блокировки — еще один тихий источник задержек. Плагин Lockable Resources полезен, когда тестам нужен эксклюзивный доступ к общей базе данных, аппаратному устройству или пространству имен для staging. Он становится болезненным, когда слишком много работы находится внутри блокировки. Держите заблокированный участок как можно меньше. Соберите артефакт вне блокировки, получите блокировку, выполните только шаг с общим ресурсом и освободите ее.

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

Время checkout: Git может быть всей проблемой

Медленный checkout распространен в старых установках Jenkins, потому что репозитории постепенно растут. Никто не замечает первые несколько больших бинарников, а затем однажды каждая сборка платит за годы истории.

Используйте настройки Git-плагина осторожно. Мелкий клон может помочь заданиям, которым нужен только текущий коммит, но он может сломать сборки, которые вычисляют версии из тегов или сравнивают с предыдущими коммитами. Получение тегов также может добавить неожиданное время в репозиториях с большим количеством тегов. Если заданию не нужны теги, отключите их получение. Если пайплайн проверяет несколько репозиториев, измеряйте время каждого checkout отдельно, чтобы один медленный репозиторий зависимостей не прятался внутри общего этапа «SCM».

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

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

Кэши зависимостей нуждаются во владельце

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

Для Maven и Gradle постоянный локальный репозиторий или кэш сборки может уменьшить повторные загрузки. Кэш должен находиться за пределами временной рабочей области. Он также должен быть безопасным для параллельных сборок. Локальный репозиторий Maven обычно подходит для обычного чтения зависимостей, но прерванные загрузки могут оставить поврежденные файлы. Если вы видите ошибки контрольной суммы или поврежденные артефакты, очистите конкретный путь зависимости вместо того, чтобы по привычке удалять весь кэш.

Для npm предпочитайте npm ci для воспроизводимых установок и кэшируйте кэш пакетов npm, а не node_modules, если вы не уверены, что операционная система, архитектура ЦП, версия Node и lockfile стабильны. Кэширование node_modules для разных образов агентов — это классический способ получить сбои нативных модулей, которые происходят только в CI.

Для Docker-сборок наиболее ценным кэшем обычно является кэш слоев. Поместите стабильные шаги установки зависимостей перед шагами копирования исходного кода в Dockerfile. Если демон Docker изолирован для каждого pod сборки и запускается пустым каждый раз, локальное кэширование слоев не сильно поможет. В этом случае используйте экспорт/импорт кэша BuildKit или кэш на основе реестра, если ваша среда это поддерживает.

Время тестирования: параллелизация с осторожностью

Тесты часто являются самой длинной частью здорового пайплайна. Цель не просто запускать больше вещей параллельно. Цель — сократить обратную связь без создания нестабильных результатов.

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

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

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

Здоровье контроллера все еще имеет значение

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

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

Избегайте запуска сборок на контроллере. Это может показаться безвредным для небольшого задания, но это усложняет расследование инцидентов. Контроллер должен координировать. Агенты должны компилировать, тестировать, упаковывать и развертывать.

Практический порядок действий

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

1. Измерьте время в очереди по сравнению со временем выполнения.
2. Найдите самый медленный этап из последних сборок.
3. Сравните медленный запуск с нормальным.
4. Проверьте, является ли задержка ожиданием, checkout, загрузкой зависимостей, тестами, упаковкой или развертыванием.
5. Исправьте одно узкое место и измерьте снова.

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