Protocolo: Qual o impacto do paralelismo de jobs no tempo total de execução de um pipeline CI/CD com GitLab Runner?
Este protocolo mede como diferentes níveis de paralelismo afetam o tempo total de execução de pipelines CI/CD usando GitLab Runner em ambiente controlado. O objetivo é identificar o ponto ótimo de paralelismo antes de saturar recursos e perder eficiência.
Roteiro para estudo em ambiente de laboratório ou de teste. Execute apenas em equipamentos, redes e contas que você tenha autorização para usar, com backup e homologação próprios. Comandos podem causar indisponibilidade ou perda de dados. Software e marcas citados pertencem aos seus titulares. Termos de Uso.
Como o aumento do paralelismo de jobs em um pipeline CI/CD afeta o tempo total de execução no GitLab Runner?
Hipótese
Aumentar o paralelismo dos jobs reduz o tempo total do pipeline até um limite, após o qual há pouca ou nenhuma melhora devido à saturação de CPU e I/O.
Variáveis
| Independentes (o que varia) | nível de paralelismo (número de jobs concorrentes configurados no runner) |
|---|---|
| Dependentes (o que se mede) | tempo total de execução do pipeline (segundos) |
| Controladas (o que fica fixo) | hardware do runner (CPU, RAM, disco); versão do GitLab Runner; pipeline YAML idêntico (mesmos jobs, scripts e artefatos); carga do sistema (sem outros processos relevantes); rede local (sem variações de latência ou banda) |
Ambiente
Máquina dedicada rodando Linux, com GitLab Runner instalado (versão conforme documentação oficial), pipeline de teste com jobs idênticos (exemplo: uso de sysbench para simular workload CPU-bound), monitoramento de recursos via Prometheus Node Exporter.
Procedimento
- Preparação
Instale o GitLab Runner na máquina dedicada e registre um runner shell.
consulte a documentação oficial para registro - Configuração
Configure o arquivo config.toml do runner para o nível de paralelismo desejado (parâmetro concurrent = N).
sudo nano /etc/gitlab-runner/config.toml - Pipeline
Crie um pipeline de teste com N jobs idênticos executando sysbench CPU por tempo fixo.
sysbench cpu --time=30 run - Execução
Execute o pipeline e registre o tempo total de execução (start/finish no GitLab CI).
- Repetição
Repita para cada valor de paralelismo (exemplo: 1, 2, 4, 8, 16), 5 vezes cada.
- Monitoramento
Colete métricas de uso de CPU e load average via Prometheus durante os testes.
Planilha de coleta
| paralelismo_configurado (inteiro) | execucao_id (inteiro) | tempo_total_pipeline (segundos) | cpu_usage_medio (porcentagem) | load_average (valor absoluto) |
|---|---|---|---|---|
| EXEMPLO: 4, 3, 125, 85.2, 4.7 | ||||
Repetições recomendadas: 5. Baixe a planilha vazia em CSV: colunas prontas.
Análise
Calcule média, mediana e desvio padrão do tempo total para cada nível de paralelismo. Compare os tempos para identificar o ponto de saturação. Analise gráficos de tempo vs. paralelismo e uso de CPU. Interprete onde há ganho real e onde há gargalo.
Critérios de decisão
- Redução consistente do tempo total até o ponto de saturação
- Aumento de uso de CPU proporcional ao paralelismo
- Estabilidade dos resultados entre repetições (desvio padrão baixo)
Fontes de erro e mitigação
- Variação de carga do sistema: isole o runner
- Flutuação de rede: use jobs CPU-bound
- Cache de disco: limpe entre execuções se necessário
Referências
- fonte oficial · GitLab Inc. (docs.gitlab.com)
- fonte oficial · GitLab Inc. (docs.gitlab.com)
- Publicado
- 09/09/2026
- Última revisão
- 09/09/2026
- Versão do conteúdo
- 1.0
- Referências
- 2 oficiais
- Revisão técnica
- redação e revisão por IA, URLs conferidas na publicação
- Status
- Atual
