Sobre o Governador
O Governor é um monitor interno para a atividade do Git em sua instância. Use o ghe-governor comando para ver quais repositórios, usuários, endereços IP e operações git estão criando carga.
Use esses dados quando o uso de CPU, memória ou disco aumentar e você precisar confirmar se o tráfego git é a causa. Para sintaxe de comando e subcomandos, consulte Utilitários de linha de comando.
O governador registra somente operações do Git. Ele não inclui a API ou o tráfego da Web. Para inspecionar as operações em execução no momento, consulte o ghe-btop utilitário em Utilitários de linha de comando.
Sobre arquivos de dados do Governor
O Governor armazena seus dados em arquivos em /data/user/governor/. Cada arquivo contém uma hora de dados e é mantido por duas semanas. Os nomes de arquivo contêm carimbos de data/hora Unix que indicam o período de tempo que cada arquivo abrange.
Observação
Na GitHub Enterprise Server versão 3.13 e anterior, os arquivos de dados do Governor estão localizados /data/user/gitmon/ e usam o padrão gitmon.<timestamp>.dbde nomenclatura.
Para confirmar o intervalo de dados atualmente mantidos em disco, converta os carimbos de data/hora nos nomes de arquivo mais antigos e mais recentes em datas legíveis por humanos.
for epoch in $(sudo ls /data/user/governor/ 2>/dev/null | grep '^governor\.' | sort | sed -n '1p;$p' | cut -f2 -d.); do echo "${epoch} = $(date -d @${epoch})"; done
A saída mostra a hora de início dos arquivos de dados mais antigos e mais recentes.
1551186000 = Tue Feb 26 13:00:00 UTC 2019
1552392000 = Tue Mar 12 12:00:00 UTC 2019
Antes de começar
Antes de executar consultas do Governor, colete estas informações:
- Acesso SSH ao dispositivo. Você precisa de acesso ao shell administrativo para executar
ghe-governor. Consulte Acessar o shell administrativo (SSH). - Qual nó consultar. Para implantações autônomas ou de alta disponibilidade, comece no nó primário. Para clusters, execute consultas em cada
git-servernó porque nenhum nó único contém todo o tráfego git. - A janela de impacto. Observe os horários de início e término da degradação relatada para que você possa definir o escopo de consultas com
-te-u. - Nomes de repositório ou de organização, se os usuários relataram problemas com repositórios ou organizações específicas.
Identificar se o Git está contribuindo para carregar
Comece com um resumo amplo e, em seguida, atribua carga a repositórios ou programas específicos.
-
Resumir todas as atividades recentes do Git em sua instância:
ghe-governor health -
Localize repositórios com o tempo de resposta médio mais lento:
ghe-governor aggregate repo avg_rt -
Localize repositórios com a operação única mais longa:
ghe-governor aggregate repo max_rt -
Localize as operações individuais mais lentas (não agrupadas):
ghe-governor top rt -n 50 -
Localize os repositórios que consomem mais tempo de CPU:
ghe-governor aggregate repo cpu -
Para um repositório que se destaca, localize qual subprograma git é responsável pelo uso da CPU:
ghe-governor aggregate program cpu -r OWNER/REPOSITORY -
Localize os repositórios onde
pack-objectsmais consumiu o tempo de CPU. Opack-objectsprograma reúne dados enviados aos clientes durante clones e buscas; uma contagem alta coloca uma pressão significativa de CPU e memória no dispositivo:ghe-governor aggregate repo cpu -P pack-objects -
Localize as operações individuais que usaram mais tempo de CPU (não agrupadas):
ghe-governor top cpu -n 50 -
Localize os repositórios que conduzem a maioria das gravações de disco durante um intervalo de tempo específico:
ghe-governor aggregate repo disk_write_kb -t START-TIME -u END-TIME -
Verifique se há alta simultaneidade, o que indica muitas operações git em execução simultaneamente:
ghe-governor aggregate repo max_parallelism
Se os resultados apontarem para um repositório ou programa específico, continue com a seção relevante abaixo.
Identificar o clone superior e buscar o tráfego
O upload-pack programa manipula os dados fornecidos aos clientes durante clones e buscas. Use essas consultas para localizar quais repositórios, usuários e endereços IP estão impulsionando a atividade de clonagem e busca mais.
-
Contar operações de clonagem e busca por repositório:
ghe-governor aggregate repo count -P upload-pack -
Identifique os usuários que executam clones e busca e conte suas operações:
ghe-governor aggregate user_id count -P upload-pack -
Identifique os endereços IP que geram mais solicitações de clonagem e busca. Um pequeno conjunto de endereços IP com uma contagem alta geralmente indica uma frota de executores de CI:
ghe-governor aggregate ip count -P upload-pack -
Medir o volume total de dados atendidos por repositório:
ghe-governor aggregate repo uploaded_kb -P upload-pack -
Medir o volume médio de dados carregados por usuário:
ghe-governor aggregate user_id avg_uploaded -P upload-pack -
Localize o clone de pico e busque simultaneidade por repositório. A
MAXPLcoluna mostra o maior número de operações simultâneas registradas para cada repositório. Um valor alto para um pequeno número de repositórios sugere um rebanho estrondoso:ghe-governor aggregate repo max_parallelism -P upload-pack -
Localize as maiores operações individuais de clonagem ou busca (não agrupadas):
ghe-governor top uploaded -P upload-pack -n 50
Identificar o tráfego pesado por push
Os receive-pack programas e os spokes-receive-pack programas manipulam os dados recebidos dos clientes durante pushes. Use essas consultas para localizar quais repositórios, usuários e endereços IP estão gerando a atividade mais push.
-
Contar operações de push por repositório:
ghe-governor aggregate repo count -P receive-pack -P spokes-receive-pack -
Identifique os usuários que estão enviando por push para uma organização e conte suas operações de push:
ghe-governor aggregate user_id count -o ORGANIZATION -P receive-pack -P spokes-receive-pack -
Medir o volume total de dados recebidos por repositório:
ghe-governor aggregate repo received_kb -P receive-pack -P spokes-receive-pack -
Identifique os endereços IP que enviam mais dados por push:
ghe-governor aggregate ip received_kb -P receive-pack -P spokes-receive-pack -
Encontre as maiores operações de push individuais (não agrupadas):
ghe-governor top received -P receive-pack -P spokes-receive-pack -n 50
Restringir a análise
Você pode adicionar qualquer combinação das seguintes opções a um ghe-governor top ou ghe-governor aggregate comando para concentrar a consulta em uma janela de tempo, repositório, proprietário ou programa específico.
Filtros de tempo
| Opção | Description |
|---|---|
-t <timespec> | Considere apenas as operações desde uma determinada hora de início. O padrão é 48 horas atrás. |
-u <timespec> | Considere somente operações até uma determinada hora de término. O padrão é a hora atual. |
Os formatos a seguir são aceitos para <timespec>.
| Formato | Example | Meaning |
|---|---|---|
| Carimbo de data/hora unix | -t 1371614483 | Segundos desde 1º de janeiro de 1970 |
| carimbo de data/hora Java | -t 1371614483637 | Milissegundos desde 1º de janeiro de 1970 |
| Dias relativos | -t 1d | O último dia |
| Horas relativas | -t 2h | As últimas duas horas |
| Minutos relativos | -t 20m | Os últimos vinte minutos |
Filtros de escopo
| Opção | Description |
|---|---|
-r <owner>/ | Considere apenas as operações correspondentes a um determinado proprietário e repositório. Especifique essa opção várias vezes para corresponder a vários repositórios. |
-o <owner> | Considere apenas as operações correspondentes a um determinado proprietário, como um usuário ou uma organização. Especifique essa opção várias vezes para corresponder a vários proprietários. |
-P <program> | Considere apenas as operações que executaram um determinado subprograma Git, como upload-pack, , receive-packou pack-objects``rev-list. Especifique essa opção várias vezes para corresponder a vários programas. |
-I <address> | Considere somente operações de um endereço IP específico. Especifique essa opção várias vezes para corresponder a vários endereços. |
Opções de saída
| Opção | Description |
|---|---|
-j | Defina o formato de saída como JSON em vez de uma tabela ASCII. |
-n <N> | Limite a saída a N registros. O padrão é 20 para consultas de agregação e 200 para consultas principais. |
--count-only | Mostrar somente as colunas e COUNT as KEY colunas. Aplica-se apenas a consultas de agregação. |
Interpretando colunas de resultados
As abreviações a seguir aparecem em ghe-governor tabelas de resultados.
| Coluna | Meaning |
|---|---|
AVG RT | Tempo médio, em segundos, que as invocações do Git levaram |
MAX RT | Tempo de execução, em segundos, da invocação de execução mais longa, por host |
MAXPL / AVGPL | Paralelismo máximo e médio: quantas invocações git estavam pendentes ao mesmo tempo |
CPU/SEC | Segundos de tempo de CPU usado pelo Git por segundo do tempo do relógio de parede. Divida pelo número de núcleos de CPU e multiplique por 100 para obter a porcentagem de CPU específica do Git. Esse valor não pode exceder o número de núcleos de CPU. |
UPL | Dados que o servidor carregou para clientes, como durante buscas e clones |
RECV | Dados que o servidor recebeu de clientes, como durante pushes |
As READcolunas , WRITEe , UPLsão RECV relatadas em gigabytes (GB), e a taxa correspondente é relatada em megabytes por segundo (MB/s).
Interpretar padrões comuns
A tabela a seguir mapeia padrões comuns de saída do Governor para suas causas prováveis.
| Pattern | Causa provável |
|---|---|
Contagem alta upload-pack de um pequeno conjunto de endereços IP | Uma frota de executores de CI está clonando repetidamente um ou mais repositórios em vez de reutilização de check-outs locais |
Alto max_parallelism para um pequeno número de repositórios | Rebanho estrondoso: muitos corredores disparando clones simultâneos ao mesmo tempo, muitas vezes porque os trabalhos agendados começam simultaneamente |
Grande uploaded_kb por repositório combinado com alta avg_uploaded por usuário | Clones completos repetidos; os clientes não estão reutilizando check-outs locais ou não estão usando clones rasos ou parciais |
Alta received_kb para um repositório ou organização | Carga de trabalho com uso intensivo de push; pode envolver arquivos binários grandes ou confirmações frequentes em um monorepo |
Alta pack-objects CPU com contagens de operações moderadas | Empacotamento de objeto caro; o repositório pode se beneficiar de uma execução de manutenção ou do uso do lado do cliente de clones parciais com --filter |
Alto avg_rt ou max_rt para um repositório | Operações lentas; geralmente causado por grandes pack-objects execuções, alta simultaneidade ou contenção de recursos de outra carga de trabalho |
Ações recomendadas para redução de carga do Git
Se os dados do Governor mostrarem que uma frota de repositórios, usuários ou executores está gerando carga excessiva, as ações a seguir podem reduzir o impacto.
- Reutilize os check-outs locais. Substitua clones novos por
git fetchfluxos de trabalho automatizados. Isso evita a transferência do grafo de objeto completo em cada execução. - Use clones rasos. Para fluxos de trabalho que não exigem histórico de confirmação completo, passe
--depthpara o comando clone, por exemplogit clone --depth 1. Isso reduz os dados transferidos e o trabalhopack-objectsdeve ser feito. - Use clones parciais. Para repositórios com objetos binários grandes ou muitos arquivos não necessários em um determinado fluxo de trabalho, use
--filterpara solicitar apenas os objetos que o fluxo de trabalho requer, por exemplogit clone --filter=blob:none. - Adicione um proxy de cache ou espelho local. Para frotas de executores grandes que clonam os mesmos repositórios repetidamente, um proxy pull-through ou espelho local pode absorver o tráfego de busca e reduzir a carga em sua instância.
- Escalonar trabalhos agendados. Deslocamento de fluxos de trabalho de CI/CD disparados em um agendamento para que nem todos os executores comecem ao mesmo tempo, reduzindo o tamanho de intermitências de clone simultâneas.
- Reduza o paralelismo do fluxo de trabalho. Fluxos de trabalho que clonam vários repositórios em paralelo podem ser reconfigurados para limitar a simultaneidade e espalhar a carga ao longo do tempo.
Quando entrar em contato com o GitHub Suporte
Entre em contato Suporte do GitHub Enterprise e inclua um pacote de suporte se qualquer uma das opções a seguir se aplicar.
- O desempenho permanece degradado depois de reduzir a pressão de clone ou trabalhos agendados escalonados.
- Sua instância está atendendo a erros de Git generalizados ou falhas de conexão que não são explicadas pela carga de trabalho do cliente.
- O Administrador mostra valores persistentes
max_parallelismsugerindo que a instância está em capacidade ou próxima, e as alterações de carga de trabalho sozinhas são improváveis de resolver o problema. - Você vê um padrão claro na saída do Governador, mas não tem certeza de como interpretá-lo ou que ação tomar.
Para obter mais informações sobre como gerar um pacote de suporte, consulte Fornecendo dados para GitHub suporte.
Leitura adicional
Para obter mais informações sobre como monitorar recursos do sistema, consulte Sobre os painéis de controle do monitor.