Enterprise Server 3.20 está disponível no momento como versão candidata a lançamento.

Verificar a capacidade do sistema antes de atualizar

Antes de atualizar o GitHub Enterprise Server, você deve realizar essas verificações de capacidade e executar as etapas recomendadas.

A atualização para versões mais recentes do GitHub Enterprise Server normalmente aumenta o consumo de recursos. Cada versão de recurso adiciona novas funcionalidades, algumas habilitadas por padrão, outras opcionais, o que requer mais capacidade de processamento. Os padrões de uso do cliente também afetam a demanda; por exemplo, empresas com dezenas de milhares de organizações podem observar maior uso de recursos.

Os aumentos de recursos geralmente aparecem como maior utilização da CPU, mais IOPS (operações de E/S por segundo), maior uso de memória ou maiores pendências na fila do Aqueduct. Para se preparar para essas alterações, verifique a capacidade disponível do sistema e aplique as recomendações de correção antes de atualizar. Execute essas verificações durante os horários mais movimentados do dia e da semana para obter resultados mais precisos.

Requisitos de recursos

Antes de atualizar sua instância, é crucial verificar se o sistema atende aos requisitos de recursos necessários:

  1.        [Uso da CPU abaixo de 70%](#cpu-usage-below-70)

  2.        [Uso de memória abaixo de 70%](#memory-usage-below-70)

  3.        [Disco não saturado](#disk-not-saturated)

  4.        [Fila de Unicorn entre 200 e 300](#unicorn-queue-under-200300)

  5.        [Pendências do Aqueduct em menos de 1–2 horas](#aqueduct-backlog-under-12-hours)

Uso da CPU abaixo de 70%

  1.           **Verificar a utilização da CPU.**

No Console de Gerenciamento, acesse a página do monitor (https://HOSTNAME.com:8443/setup/monitor) e visualize o grafo CPU.

  • Se a utilização estiver regularmente abaixo de 70%, continue para o Uso de memória.
  • Se a utilização estiver regularmente acima de 70%, o sistema não atenderá aos critérios de atualização.
  1.           **Compare a utilização com a média da carga da CPU.**

A comparação ajuda a identificar a possível saturação do disco.

  • Acesse a exibição da Integridade Operacional e verifique o gráfico Load.

  • Na matriz, localize o valor em que a linha shortterm intersecciona com a coluna avg.

  • Calcule o percentual médio da carga:

    (short-term avg ÷ number of vCPUs) × 100

  • Na mesma exibição, verifique o grafo CPU. Na matriz, localize o valor em que a linha idle intersecciona com a coluna avg. Subtraia esse valor de 100 para obter a utilização.

  1.        **Interprete os resultados.**

    Se o percentual médio de carga da CPU for maior que 50% acima da utilização, isso provavelmente indicará a contenção de recursos. Não prossiga com a atualização até que você tenha investigado a possível saturação de disco (consulte Disco não saturado).

Uso de memória abaixo de 70%

  1.           **Verifique o uso da memória.**

No Console de Gerenciamento, acesse a página do monitor (https://HOSTNAME.com:8443/setup/monitor) e visualize o gráfico Memory.

  1.        **Interprete os resultados.**
    • Se o uso de memória estiver regularmente abaixo de 70%, continue para Disco não saturado.
    • Se o uso de memória estiver regularmente acima de 70%, o sistema não atenderá aos critérios de atualização.

Disco não saturado

  1.           **Verifique as especificações do provedor.**

Se seu provedor de nuvem ou hardware oferecer métricas de utilização de disco, use-as para confirmar se o disco está saturado.

  • Se as métricas não estiverem disponíveis, solicite as especificações de disco do seu provedor, incluindo a taxa de transferência máxima e o IOPS máximo.
  • Compare esses limites com o uso de disco observado. Se o uso estiver se aproximando dos valores máximos, o disco está saturado.
  1.           **Verifique os grafos de disco no Console de Gerenciamento.**

Acesse a página do monitor (https://HOSTNAME.com:8443/setup/monitor).

  • Exiba os grafos Disk Operations e Disk Traffic.

  • Compare os valores do eixo Y com as especificações do seu provedor (não a escala máxima mostrada no grafo).

  • Examine os dados e os discos raiz.

Esses gráficos estão disponíveis na exibição "Application Insights".

  1.           **Interprete os resultados.**

Se o uso do disco estiver se aproximando dos limites definidos pelo provedor, o disco está saturado. Nesse caso, o sistema não atende aos critérios para atualização.

Fila de Unicorn abaixo de 200 a 300

  1.           **Verifique o grafo de solicitações enfileiradas.**

No Console de Gerenciamento, acesse a página do monitor (https://HOSTNAME.com:8443/setup/monitor) e visualize o gráfico Queued Requests.

Esse gráfico está disponível na exibição "Application Insights".

  1.        **Interprete os resultados.**
    • Se as solicitações enfileiradas estiverem consistentemente abaixo de 200, prossiga para o backlog do Aqueduct com menos de 1 a 2 horas.
    • Se as solicitações na fila estão regularmente entre 200 e 300, o sistema não atende aos critérios de atualização.
  2.           **Opcional: Verifique a utilização dos trabalhadores unicorn.**

No shell administrativo, execute:

ps -ef | grep unicorn | grep -v gitauth | grep -v ".rb" | grep -v init | grep git
 ```

Olhe para a última coluna do resultado. Se todos os processos mostrarem `> 90% utilization`, mais trabalhadores unicórnio são necessários.

### Lista de pendências de Aqueduct abaixo de 1 a 2 horas

1. 
              **Verifique a profundidade da fila do Aqueduct.**
No Console de Gerenciamento, acesse a página do monitor (`https://HOSTNAME.com:8443/setup/monitor`) e visualize o gráfico `Aqueduct queue depth`.



Esse gráfico está disponível na exibição "Application Insights".


1. 
           **Interprete os resultados.**

* Se a lista de pendências durar menos de 1 a 2 horas, você atenderá a esse requisito.
* Se a lista de pendências **costuma durar mais de 1 a 2 horas**, o sistema não atenderá aos critérios de atualização.

1. Monitore a `index_high` fila.
Grandes implantações podem ter aumentos significativos na profundidade da fila `index_high`, o que pode piorar os atrasos. Preste atenção especial a essa fila durante o monitoramento.

Se **todos os critérios** (CPU, memória, disco, fila do Unicorn, lista de pendências do Aqueduct) forem atendidos, você poderá prosseguir com a atualização para a versão do recurso de destino. Após a atualização, é provável que o consumo de recursos aumente ainda mais.

Se **algum critério não estiver atendido**, resolva os problemas subjacentes antes de tentar atualizar.

## Atualizar hardware e otimizar processos de trabalho

Se o sistema não atendeu a um ou mais dos requisitos de recursos, você precisará aumentar a capacidade antes de atualizar. As seções a seguir descrevem como adicionar recursos de hardware e ajustar a configuração de trabalho para resolver gargalos comuns.

1. 
           [CPU acima de 70%](#cpu-above-70)
1. 
           [Memória acima de 70%](#memory-above-70)
1. 
           [Disco saturado](#disk-saturated)
1. 
           [Fila de Unicórnio acima de 200–300](#unicorn-queue-above-200300)
1. 
           [Fila do Aqueduct acima de 1 a 2 horas](#aqueduct-backlog-above-12-hours)

### CPU acima de 70%

Se a utilização da CPU estiver regularmente acima de 70%:

* 
             **Aumente os recursos da CPU.**
Adicione pelo menos 20% de vCPUs.
* 
             **Considere novos trabalhadores.**
Aloque 1 vCPU por trabalhador. Por exemplo, se você adicionar 5 trabalhos do Unicorn e 10 trabalhos Resque, aumente as vCPUs em pelo menos 15.

### Memória acima de 70%

Se o uso de memória estiver regularmente acima de 70%:

* 
             **Aumente a memória.**
Adicione RAM para reduzir o uso médio para menos de 70%.
* 
             **Considere novos funcionários.**
Aloque 1 GB de memória por trabalhador. Por exemplo, se você adicionar 5 trabalhos do Unicorn e 10 trabalhos Resque, aumente a memória em pelo menos 15 GB.

### Disco saturado

Se a verificação de saturação do disco indicar saturação, atualize para discos com maior taxa de transferência e IOPS máxima.

### Fila de Unicorn acima de 200 a 300

Se as solicitações do Unicorn forem enfileiradas consistentemente acima de 200 a 300, talvez seja necessário adicionar mais trabalhos do Unicorn. Siga estas etapas para determinar o número total de trabalhadores-alvo e atualizar sua configuração.

#### 1. Estimar trabalhos adicionais

Execute o seguinte comando durante o horário de pico para visualizar a utilização por trabalhador:

```shell
ps -ef | grep unicorn | grep -v gitauth | grep -v ".rb" | grep -v init | grep git

Exemplo de saída:

git      3048972 3045762  0 Aug01 ?        00:07:47 unicorn 3-16-nightly.ghe-test.com[6e6ad46] worker[00]: 20491 reqs,  10.8 req/s,   13ms avg,   85.2% util
git      3048979 3045762  0 Aug01 ?        00:07:53 unicorn 3-16-nightly.ghe-test.com[6e6ad46] worker[01]: 20951 reqs,  12.5 req/s,   13ms avg,   80.3% util
git      3048985 3045762  0 Aug01 ?        00:08:04 unicorn 3-16-nightly.ghe-test.com[6e6ad46] worker[02]: 21502 reqs,  10.5 req/s,   15ms avg,   76.5% util
git      3048992 3045762  0 Aug01 ?        00:07:45 unicorn 3-16-nightly.ghe-test.com[6e6ad46] worker[03]: 20249 reqs,  14.2 req/s,   15ms avg,   86.9% util

A média é de 12 solicitações/segundo.

Com esse resultado, calcule a média de solicitações por segundo (req/s).

  • No exemplo acima: 12 req/s.

  • A meta é reduzir as solicitações enfileiradas para 100 ou menos.

  • Fórmula:

    (Queued requests – 100) ÷ avg req/s

  • Exemplo: (280 - 100) ÷ 12 = 15 trabalhos adicionais necessários.

    Dica

    Se você quiser confirmar esses resultados, entre em contato conosco acessando Suporte do GitHub Enterprise, carregando um pacote e solicitando o número total de trabalhos Unicorn.

2. Verificar a configuração atual

Verifique se o número total de trabalhos (Unicorn + Resque) não excede as vCPUs. Aloque pelo menos 1 vCPU por trabalho.

Verifique os números atuais:

  • Trabalhadores de unicórnio

    ps -ef | grep unicorn | grep -v gitauth | grep -v ".rb" | grep -v init | grep git | wc -l

    Adicione o número calculado de novos trabalhadores a este valor para obter a meta total.

  • Trabalhadores Resque

    ps -ef | grep aqueduct-1.1.0 | grep -v "grep aqueduct-1.1.0" | wc -l

3. Ajustar a configuração

Se a soma de trabalhos Unicorn + Resque exceder as vCPUs, adicione vCPUs antes de continuar.

Atualize o número de trabalhos Unicorn:

ghe-config app.github.github-workers <NUM-WORKERS>
ghe-config-apply

Substitua pelo número total alvo de trabalhadores Unicorn.

Lista de pendências do Aqueduct acima de 1 a 2 horas

Se os trabalhos do Aqueduct ficarem regularmente pendentes por mais de 1 a 2 horas, adicione trabalhos resqued-low para reduzir o risco de backups de fila. Esse problema geralmente piora após a atualização.

1. Adicionar trabalhos resqued-low

  • Aumente o número de trabalhadores em 5 a 10. Lembre-se da capacidade da CPU: cada trabalho requer pelo menos 1 vCPU.
ghe-config app.github.resqued-low-workers <NUM-WORKERS>
ghe-config-apply

Substitua pelo novo número total de trabalhadores resqued-low.

2. Validar a contagem total de trabalhadores

O número combinado de trabalhos Unicorn + Resque não deve exceder o número total de vCPUs. Consulte Unicorn fila acima de 200–300 para obter instruções sobre como verificar a configuração atual dos trabalhadores.