Verificar a capacidade do sistema antes de atualizar

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:

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

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

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

          [Fila do Unicorn com menos de 200–300](#unicorn-queue-under-200300)

          [Lista de pendências no Aqueduct inferior a 1–2 horas](#aqueduct-backlog-under-12-hours)

Uso da CPU abaixo de 70%

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

No Console de Gerenciamento, acesse a página do monitor (https://HOSTNAME.com:8443/setup/monitor) e exiba 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.

          **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 grafo 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.

```
       **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%

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

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

```
       **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

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

          **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".

          **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

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

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

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

```
       **Interprete os resultados.**
```
- Se as solicitações enfileiradas estão consistentemente abaixo de 200, prossiga para a Lista de pendências do Aqueduct abaixo 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.
```
          **Opcional: verifique a utilização do trabalho do 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 trabalhos do Unicorn serão necessários.

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

          **Verifique a profundidade da fila do Aqueduct.**

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

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

```
       **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.
```
          **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.

       [CPU acima de 70%](#cpu-above-70)

       [Memória acima de 70%](#memory-above-70)

       [Disco saturado](#disk-saturated)

       [Fila de Unicórnio acima de 200–300](#unicorn-queue-above-200300)

          [Lista de pendências no Aqueduct superior a 1–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 trabalhos.**
```
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 trabalhos.**
```
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:

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 Fila de Unicorn acima de 200 a 300 para obter instruções sobre como verificar a configuração de trabalho atual.

Neste artigo