Gargalos Comuns de Desempenho no Jenkins e Como Corrigi-los

Uma instância lenta do Jenkins geralmente não tem uma única causa. A interface parece pesada, os builds ficam na fila, os agentes desconectam, os logs demoram para abrir e alguém diz: "O Jenkins caiu de novo." Por trás dessa reclamação, o problema geralmente é um de alguns gargalos comuns: pressão no heap do controlador, disco lento, agentes sobrecarregados, problemas com plugins, mau comportamento de pipelines ou atrasos na rede para sistemas de controle de versão e artefatos.

A maneira mais rápida de corrigir o desempenho do Jenkins é separar problemas do controlador de problemas de build. Se a interface do Jenkins, a fila e as páginas de jobs estão lentas mesmo quando nenhum build está em execução, comece pelo controlador. Se a interface está boa, mas os builds demoram muito, comece pelos agentes, workspaces, caches e sistemas externos.

Memória do controlador e coleta de lixo

O controlador do Jenkins é um processo Java. Ele precisa de heap suficiente para configuração de jobs, plugins, metadados de build, estado da fila e requisições web. Quando o heap é muito pequeno, o controlador gasta muito tempo na coleta de lixo. Quando um plugin vaza memória ou armazena muitos dados na memória, aumentar o heap pode apenas adiar o próximo incidente.

Os sintomas incluem interface lenta, pausas longas, OutOfMemoryError, desconexões frequentes de agentes ou atrasos na fila de build que não correspondem aos executores disponíveis.

Verifique o processo e os logs primeiro:

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

Para um controlador moderado, um heap de 2 a 4 GB pode ser suficiente. Instalações movimentadas podem precisar de mais. Não defina cegamente o heap para a maior parte da RAM da máquina. O SO ainda precisa de memória para cache do sistema de arquivos, sobrecarga de processos e agentes de monitoramento.

Opções típicas de serviço são assim:

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

Após alterar as opções da JVM, reinicie o Jenkins durante uma janela de manutenção e observe o comportamento sob carga normal. Se a memória aumentar constantemente por dias e nunca se estabilizar, faça um dump de heap e revise plugins atualizados ou instalados recentemente. Mantenha os plugins atualizados, mas evite atualizar um grande conjunto de plugins sem um plano de reversão.

Espaço em disco e I/O de disco

O Jenkins usa disco constantemente. JENKINS_HOME armazena configuração de jobs, registros de build, impressões digitais, dados de plugins, segredos, logs e, às vezes, muitos artefatos. Os agentes usam disco para workspaces, caches de dependências, camadas Docker, relatórios de teste e arquivos temporários.

Um disco cheio é óbvio. Um disco lento é mais irritante porque nada parece quebrado; tudo apenas espera.

Verifique capacidade e latência:

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

Se %util e tempos de espera estiverem altos durante os builds, o disco é um gargalo. Correções comuns são mover workspaces para armazenamento mais rápido, podar camadas Docker antigas, reduzir a retenção de artefatos e impedir que jobs arquivem diretórios inteiros quando apenas relatórios ou pacotes são necessários.

Defina políticas de descarte de builds nos jobs:

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

Tenha cuidado com a limpeza manual em JENKINS_HOME. Não exclua arquivos XML aleatórios ou diretórios de plugins enquanto o Jenkins estiver em execução. Use as configurações de retenção do Jenkins, ferramentas de limpeza específicas de plugins e backups.

Muito trabalho no controlador

Uma das configurações mais prejudiciais é executar builds no controlador. O controlador não deve compilar, executar testes, construir imagens Docker ou fazer checkouts grandes.

Defina executores do controlador como 0 na maioria das instalações. Coloque os builds nos agentes. Se você já executa builds no controlador, mova-os gradualmente e observe suposições ocultas, como caminhos de ferramentas locais, vinculações de credenciais ou arquivos que existem apenas no controlador.

Verifique também pipelines para código Groovy pesado no controlador. Etapas de pipeline como sh são executadas nos agentes, mas a lógica Groovy no Jenkinsfile pode ser executada no controlador. Evite ler arquivos grandes em variáveis Groovy, construir mapas enormes ou fazer processamento JSON pesado no script do pipeline. Use shell, Python, jq ou sua ferramenta de build no agente para trabalho pesado de dados.

Agentes sobrecarregados ou incompatíveis

Se o tempo de fila for alto para um label, adicionar executores genéricos não ajudará. Um job que requer linux && docker && large-memory precisa dessa capacidade exata.

Observe os motivos da fila e o uso de labels. Em seguida, verifique o SO do agente:

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

Se um agente estiver fazendo swap, reduza os executores ou aumente a memória. Se a CPU estiver no máximo e a duração do build aumentar durante períodos de pico, reduza a concorrência ou adicione agentes. Se a espera de I/O estiver alta, mova caches e workspaces para armazenamento mais rápido ou reduza o número de jobs simultâneos nesse nó.

Para agentes Kubernetes, as solicitações de recursos são tão importantes quanto a contagem de executores do Jenkins. Um pod solicitando pouca CPU ou memória pode ser agendado em um nó já ocupado, e então o Jenkins vê um agente pronto enquanto o build arrasta. Para pods descartáveis, um executor por pod geralmente é mais fácil de raciocinar do que vários executores compartilhando o mesmo contêiner.

Problemas com plugins

Os plugins são um dos pontos fortes do Jenkins e também uma fonte comum de problemas de desempenho. Um plugin pode adicionar custo de renderização de página, atrasar o carregamento de jobs, reter muito histórico de build ou fazer chamadas externas durante ações normais da interface.

Quando o desempenho muda repentinamente, pergunte o que mudou recentemente:

• Atualização do núcleo do Jenkins.
• Atualização de plugin.
• Instalação de novo plugin.
• Nova configuração global.
• Nova versão de biblioteca compartilhada.

Use as informações de saúde "Gerenciar Jenkins", logs e changelogs de plugins. Se a interface ficou lenta após uma atualização de plugin, teste a reversão em um controlador de teste, se tiver um. Mantenha um backup de JENKINS_HOME e versões de plugins antes de grandes atualizações.

Não mantenha plugins "por precaução." Cada plugin instalado adiciona superfície de manutenção. Remova plugins não utilizados após verificar dependências de jobs.

Atrasos no SCM e repositório de artefatos

Muitos relatos de "Jenkins lento" são, na verdade, problemas com Git, registro de pacotes, registro de contêineres ou repositório de artefatos.

Verifique os logs de build para etapas lentas repetidas:

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

Se todo job espera por downloads de dependências, adicione um proxy ou cache próximo. Se git fetch estiver lento, verifique o tamanho do repositório, descoberta de branches, configurações de shallow clone e caminho de rede dos agentes para o servidor Git. Se pulls Docker forem lentos em agentes efêmeros, use um mirror de registro ou cache de registro do BuildKit.

Mantenha o diagnóstico honesto: o Jenkins agenda o trabalho, mas não pode tornar um registro de pacotes distante rápido.

Inchaço de logs e histórico de builds

Logs de console grandes tornam a renderização de páginas lenta e consomem armazenamento. Jobs que imprimem cada fixture de teste, cada resposta HTTP ou logs completos de depuração durante builds normais acabam tornando o Jenkins doloroso de usar.

Corrija o job primeiro. Reduza a verbosidade normal do log e arquive logs detalhados como artefatos compactados apenas quando necessário. Mantenha a saída do console focada no progresso e no contexto de falhas.

Em seguida, defina a retenção:

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

Para ambientes com muitos requisitos de conformidade, mova artefatos e logs de longo prazo para um sistema de armazenamento externo projetado para retenção, pesquisa e políticas de ciclo de vida.

Um caminho prático para incidentes

Quando o Jenkins está lento agora, use esta ordem:

1. Verifique se a interface do controlador está lenta.
2. Verifique CPU, memória, sintomas de GC e disco do controlador.
3. Verifique os motivos da fila e quais labels estão esperando.
4. Verifique os agentes mais ocupados quanto a CPU, memória, disco e crescimento do workspace.
5. Compare alterações recentes em plugins, jobs e bibliotecas compartilhadas.
6. Leia um log de build lento e identifique a etapa cara repetida.

Esse caminho evita ajustes aleatórios. Aumentar o heap não corrigirá um agente Docker saturado. Adicionar executores não corrigirá um disco cheio. Podar workspaces não corrigirá um plugin que causa pausas no controlador.

Mantenha o Jenkins sustentável

Instalações saudáveis do Jenkins têm hábitos simples: executores do controlador definidos como zero, agentes dimensionados para sua carga de trabalho, retenção de build configurada, caches de dependência intencionais, atualizações de plugins rastreadas e métricas básicas exportadas para Prometheus, Grafana, CloudWatch ou qualquer sistema de monitoramento que a equipe já use.

A melhor correção geralmente é pequena e específica. Mova builds Docker para agentes dedicados. Reduza a saída de log de um job barulhento. Adicione um proxy Maven. Reduza executores em um nó com swap. Remova um plugin não utilizado. Coloque retenção em um job que manteve todos os builds por anos.

O desempenho do Jenkins melhora quando você para de tratá-lo como uma caixa preta e começa a seguir o trabalho: da fila, para o controlador, para o agente, para o sistema de arquivos, para a dependência de rede e de volta ao log de build.

Exemplo: o build está lento, mas o Jenkins está bem

Suponha que os desenvolvedores relatem que as verificações de pull request levam 25 minutos. A interface do Jenkins está responsiva. A fila é curta. Os agentes estão online. O log lento mostra:

git fetch: 20 segundos
npm ci: 9 minutos
testes unitários: 4 minutos
docker build: 10 minutos
arquivar artefatos: 1 minuto

Isso não é principalmente um problema do controlador do Jenkins. As correções prováveis são cache de pacotes, ordenação de camadas Dockerfile, cache do BuildKit e talvez divisão de testes. Aumentar o heap do controlador não mudaria nada.

Exemplo: tudo espera, mas os agentes estão ociosos

Se os jobs estão na fila enquanto os agentes parecem ociosos, leia o motivo da fila. Você pode descobrir que os jobs requerem linux && docker, enquanto os agentes ociosos têm apenas linux. Ou os jobs podem estar bloqueados por disableConcurrentBuilds, um recurso bloqueável ou um plugin de nuvem que está falhando ao provisionar agentes correspondentes.

Esse tipo de gargalo é configuração, não capacidade bruta. Adicionar dois agentes incompatíveis não ajudará.

Exemplo: o controlador fica lento todas as tardes

Se a interface degradar no mesmo horário todos os dias, procure jobs agendados: indexação de branches, backups, limpeza de artefatos grandes, varreduras de vulnerabilidade ou pipelines noturnos começando muito cedo. Verifique CPU, heap e I/O de disco do controlador durante essa janela. Verifique também se muitos jobs começam exatamente no mesmo minuto devido a expressões cron como 0 2 * * *.

Em agendamentos do Jenkins, prefira temporização hash quando possível:

H 2 * * *

Isso distribui os jobs em vez de iniciar tudo no início da hora.

O que um bom monitoramento deve responder

No mínimo, o monitoramento deve responder a estas perguntas sem fazer login no servidor:

• O processo do controlador está vivo e responsivo?
• Quanto heap está sendo usado e com que frequência a coleta de lixo está sendo executada?
• Quanto tempo os jobs estão esperando na fila por label?
• Quais agentes estão offline ou reconectando repetidamente?
• Os discos do controlador e dos agentes estão perto de ficar cheios?
• Os builds estão ficando mais lentos ao longo do tempo para os mesmos jobs?

Você não precisa de um dashboard perfeito para começar. Mesmo algumas métricas e alertas para disco, heap, tamanho da fila e disponibilidade de agente pegarão muitas falhas antes que os desenvolvedores as relatem.