Resolver problemas comuns de alocação de recursos no appliance
Note
Fazer solicitações repetidas regularmente (sondagem) para o sua instância do GitHub Enterprise Server de sistemas de CI (integração contínua), servidores de build ou qualquer outro cliente (como clientes do Git ou de API) pode sobrecarregar o sistema. Isso pode levar a um ataque de negação de serviço (DoS), causando problemas significativos de desempenho e saturação de recursos.
Para evitar esses problemas, recomendamos o uso de webhooks para receber atualizações. Webhooks permitem que o sistema envie atualizações para você automaticamente, eliminando a necessidade de sondagem constante. Além disso, considere o uso de solicitações condicionais e estratégias de cache para minimizar solicitações desnecessárias. Evite executar trabalhos em lotes grandes e simultâneos (rebanhos trovejantes) e, em vez disso, aguarde que os eventos de webhook disparem ações.
Para saber mais, confira Sobre webhooks.
Recomendamos usar o painel do monitor para se manter informado sobre a integridade dos recursos do seu dispositivo e tomar decisões sobre como corrigir problemas de alto uso, como os descritos nesta página.
Para problemas críticos do sistema e antes de fazer modificações no dispositivo, é altamente recomendável entrar em contato conosco acessando o Suporte do GitHub Enterprise e incluindo seu pacote de suporte. Para obter mais informações, confira "Como fornecer dados para o Suporte do GitHub Enterprise".
Alto uso da CPU
Causas possíveis
- A CPU da instância está subprovisionada para a carga de trabalho.
- A atualização para novas versões do GitHub Enterprise Server geralmente aumenta o uso de CPU e memória devido a novos recursos. Além disso, a migração pós-atualização ou os trabalhos em segundo plano de reconciliação podem degradar temporariamente o desempenho até que sejam concluídos.
- Solicitações elevadas em relação ao Git ou à API. O aumento de solicitações para Git ou API pode ocorrer devido a vários fatores, como clonagem excessiva de repositório, processos de CI/CD ou uso não intencional por scripts de API ou novas cargas de trabalho.
- Aumento do número de trabalhos do GitHub Actions.
- Quantidade elevada de comandos Git executados em um repositório grande.
Recomendações
- Verifique se os núcleos da CPU estão provisionados adequadamente.
- Definir limites de alerta.
- Após uma atualização, verifique se as tarefas de atualização em segundo plano foram concluídas, executando
ghe-check-background-upgrade-jobs
. - Use webhooks em vez de puxar.
- Use a limitação de fluxo da API.
- Analise o uso do Git verificando as operações atuais e o tráfego do Git.
Alto uso da memória
Possíveis causas:
- A memória da instância está subprovisionada.
- Solicitações elevadas em relação ao Git ou à API. O aumento de solicitações para Git ou API pode ocorrer devido a vários fatores, como clonagem excessiva de repositório, processos de CI/CD ou uso não intencional por scripts de API ou novas cargas de trabalho.
- Serviços individuais que excedem o uso de memória esperado e ficam sem memória (OOM).
- Aumento do processamento de trabalhos em segundo plano.
Recomendações
- A memória da instância está subprovisionada para a carga de trabalho, o volume de dados, dado o uso ao longo do tempo, pode exceder os requisitos mínimos recomendados.
- Nos gráficos do Nomad, identifique os serviços com tendências de memória insuficiente que geralmente são seguidas por tendências de memória livre depois de serem reiniciados. Para saber mais, confira Sobre o painel do monitor.
- Verifique os logs de processos que estão ficando sem memória executando
rg -z 'kernel: Out of memory: Killed process' /var/log/syslog*
(para isso, primeiro faça login no shell administrativo usando SSH - consulte Acesar o shell administrativo (SSH)). - Verifique se a proporção correta de memória para serviços de CPU é atendida (pelo menos
6.5:1
). - Verifique a quantidade de tarefas enfileiradas para processamento em segundo plano - consulte Sobre o painel do monitor.
Pouco espaço em disco
Ambos os volumes de armazenamento, um montado no caminho do sistema de arquivos raiz (/
) e o outro no caminho do sistema de arquivos do usuário (/data/user
), podem causar problemas à estabilidade da instância se houver pouco espaço em disco disponível.
Lembre-se de que o volume do armazenamento raiz é dividido em duas partições de tamanho igual. Uma das partições será montada como o sistema de arquivos raiz (/
). A outra partição só será montada durante upgrades e reversões de upgrades como upgrades do /mnt/
, para facilitar as reversões, se necessário. Para saber mais, confira Visão geral do sistema.
Causas possíveis
- Falha de serviço causando aumento da quantidade de logs
- Alto uso do disco por meio do tráfego orgânico
Recomendações
- Verifique o uso do disco da pasta executando (
sudo du -csh /var/log/*
) ou forçando manualmente uma rotação de/var/log
log (sudo logrotate -f /etc/logrotate.conf
). - Verifique se há arquivos grandes no disco que foram excluídos, mas ainda têm identificadores de arquivos abertos (
ghe-check-disk-usage
). - Aumente a capacidade de armazenamento em disco - consulte Aumentar a capacidade de armazenamento.
Tempos de resposta maiores do que o comum
Possíveis causas:
- Solicitações elevadas em relação ao Git ou à API. O aumento de solicitações para Git ou API pode ocorrer devido a vários fatores, como clonagem excessiva de repositório, processos de CI/CD ou uso não intencional por scripts de API ou novas cargas de trabalho.
- Consultas lentas ao banco de dados.
- Após a atualização, o ElasticSearch elevou o uso de recursos de serviço.
- Atingir cotas de IOPS em disco e/ou contenção de E/S pesada.
- Trabalhadores saturados.
- Atrasos na entrega do webhook.
Recomendações
- Procure picos ou números sustentados nos gráficos de Operações pendentes de disco: número de operações enfileiradas.
- Verifique o painel de Solicitação/resposta de aplicativos para ver se apenas determinados serviços são afetados.
- Após uma atualização, verifique se as tarefas de atualização em segundo plano foram concluídas, executando
ghe-check-background-upgrade-jobs
. - Verifique os logs do banco de dados em busca de consultas lentas em
/var/log/github/exceptions.log
(para isso, primeiro faça login no shell administrativo usando SSH - consulte Acesar o shell administrativo (SSH)), por exemplo, verificando as 10 principais solicitações lentas por URL:grep SlowRequest github-logs/exceptions.log | jq '.url' | sort | uniq -c | sort -rn | head
. - Verifique o gráfico de Solicitações enfileiradas para determinados trabalhadores e considere ajustar sua contagem de trabalhadores ativos.
- Aumente os discos de armazenamento para aqueles com maior taxa de transferência/IOPS.
- Verifique a quantidade de tarefas enfileiradas para processamento em segundo plano - consulte Sobre o painel do monitor.
Altos índices de erro
Causas possíveis
- Solicitações elevadas em relação ao Git ou à API. O aumento de solicitações para Git ou API pode ocorrer devido a vários fatores, como clonagem excessiva de repositório, processos de CI/CD ou uso não intencional por scripts de API ou novas cargas de trabalho.
- Falha no serviço
haproxy
ou indisponibilidade de serviços individuais. - Falha na manutenção da rede do repositório ao longo do tempo.
Recomendações
- Verifique o painel de Solicitação/resposta de aplicativos para ver se apenas determinados serviços são afetados.
- Verifique os logs
haproxy
e tente identificar se os agentes mal-intencionados podem ser a causa. - Verifique se há trabalhos de manutenção de rede de repositório com falha (acesse
http(s)://[hostname]/stafftools/networks
).