Skip to main content

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

Use o Governor para identificar os padrões de tráfego git que estão gerando carga em sua instância, para que você possa solucionar problemas de operações lentas do Git e reduzir o impacto no desempenho.

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-server nó 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 -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 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-objects mais consumiu o tempo de CPU. O pack-objects programa 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 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 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çãoDescription
-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>.

FormatoExampleMeaning
Carimbo de data/hora unix-t 1371614483Segundos desde 1º de janeiro de 1970
carimbo de data/hora Java-t 1371614483637Milissegundos desde 1º de janeiro de 1970
Dias relativos-t 1dO último dia
Horas relativas-t 2hAs últimas duas horas
Minutos relativos-t 20mOs últimos vinte minutos

Filtros de escopo

OpçãoDescription
-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 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çãoDescription
-jDefina 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-onlyMostrar 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.

ColunaMeaning
AVG RTTempo médio, em segundos, que as invocações do Git levaram
MAX RTTempo de execução, em segundos, da invocação de execução mais longa, por host
MAXPL / AVGPLParalelismo máximo e médio: quantas invocações git estavam pendentes ao mesmo tempo
CPU/SECSegundos 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.
UPLDados que o servidor carregou para clientes, como durante buscas e clones
RECVDados 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.

PatternCausa provável
Contagem alta upload-pack de um pequeno conjunto de endereços IPUma 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óriosRebanho 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árioClones 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çãoCarga 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 moderadasEmpacotamento 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órioOperações lentas; geralmente causado por grandes pack-objects execuções, alta simultaneidade ou contenção de recursos de outra carga de trabalho

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 fetch fluxos 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 --depth para o comando clone, por exemplo git clone --depth 1. Isso reduz os dados transferidos e o trabalho pack-objects deve 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 --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.
  • 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_parallelism sugerindo 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.