Analisando o tráfego git em sua GitHub Enterprise Server instância

Sobre o Governador

O Governor é um monitor integrado das atividades 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 estes dados quando o uso de CPU, memória ou disco aumentar e você precisar confirmar se o tráfego do Git é a causa. Para sintaxe de comando e subcomandos, consulte Utilitários de linha de comando.

O Governor registra apenas 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 utilitário ghe-btop em Utilitários de linha de comando.

Sobre arquivos de dados do Governor

O Governor armazena seus dados em arquivos sob /data/user/governor/. Cada arquivo contém uma hora de dados e é mantido por duas semanas. Os nomes de arquivo contêm marcas de tempo Unix que indicam o período que cada arquivo abrange.

Para confirmar o intervalo de dados atualmente armazenados em disco, converta as marcas de data e hora nos nomes dos arquivos mais antigo e mais recente em datas em formato legível.

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. Em clusters, execute consultas em cada nó git-server, porque nenhum nó isolado contém todo o tráfego do 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 -t e -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 a carga

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
  

• Encontre repositórios com a operação individual 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-objects mais consumiu o tempo de CPU. O programa pack-objects reúne os dados enviados aos clientes durante operações de clone e fetch; uma quantidade elevada impõe uma carga significativa sobre a CPU e a memória do equipamento:

  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 os principais tráfegos de clone e fetch

O programa upload-pack processa os dados servidos aos clientes durante operações de clone e fetch. Use estas consultas para identificar quais repositórios, usuários e endereços IP são responsáveis pela maior parte da atividade de clonagem e busca.

• Contagem de operações de clone e fetch por repositório:

  ghe-governor aggregate repo count -P upload-pack
  

• Identifique os usuários que executam clones e fetches e conte o número de 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 MAXPL coluna 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 tráfego intenso de push

Os programas receive-pack e spokes-receive-pack processam os dados recebidos dos clientes durante os 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 individuais de push (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 valor padrão é há 48 horas.
-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
Marca temporal Unix	-t 1371614483	Segundos desde 1º de janeiro de 1970
registro de data e 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>/<repository>	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 rev-list``pack-objects. Especifique essa opção várias vezes para corresponder a vários programas.
-I <address>	Considere somente operações oriundas 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 KEY e COUNT. 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 enviou aos clientes, como durante fetches e clones
RECV	Dados que o servidor recebeu de clientes, como durante pushes

As colunas READ, WRITE, UPL e RECV são informadas em gigabytes (GB), e a taxa correspondente é informada 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 proveniente 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 checkouts locais ou não estão usando clones superficiais ou parciais
Alta received_kb para um repositório ou organização	Carga de trabalho com muitos pushes; pode envolver arquivos binários grandes ou commits frequentes em um monorepo
CPU alta com número moderado de operações	Empacotamento de objetos custoso; o repositório pode se beneficiar da execução de uma rotina de manutenção ou do uso, no lado do cliente, de clones parciais com --filter
Alto avg_rt ou max_rt para um repositório	Operações lentas; geralmente causadas por execuções longas de pack-objects, alta concorrência ou contenção de recursos causada por outra carga de trabalho

Ações recomendadas para redução de carga do Git

Se os dados do Governor indicarem que um repositório, usuário ou frota de runners está gerando carga excessiva, as ações a seguir podem reduzir o impacto.

• Reutilize os check-outs locais. Substitua clones recentes por git fetch em fluxos de trabalho automatizados. Isso evita a transferência do grafo de objeto completo em cada execução.
• Use clones superficiais. Para fluxos de trabalho que não exigem histórico de confirmação completo, passe --depth para o comando clone, por exemplo git clone --depth 1. Isso reduz tanto os dados transferidos quanto o trabalho que pack-objects precisa fazer.
• 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 --filter para solicitar apenas os objetos que o fluxo de trabalho requer, por exemplo git 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.
• Distribuir tarefas agendadas. Distribua os fluxos de trabalho de CI/CD acionados por agendamento para que nem todos os runners sejam iniciados ao mesmo tempo, reduzindo o tamanho dos picos simultâneos de clonagem.
• 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 com Suporte do GitHub Enterprise e inclua um pacote de suporte se qualquer uma das condições a seguir se aplicar.

• O desempenho permanece degradado após reduzir a pressão de clonagem ou escalonar as tarefas agendadas.
• 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 Governor mostra valores persistentes max_parallelism, sugerindo que a instância está na capacidade máxima ou próxima dela, e é improvável que somente alterações na carga de trabalho resolvam 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.