Solução de problemas de alocação de recursos

Resolver problemas comuns de alocação de recursos no appliance

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 obter mais informações, confira "Acessar o painel de monitoramento".
• 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 "Acessar o painel de monitoramento".

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 obter mais informações, 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 "Acessar o painel de monitoramento".

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).