Como faço para solucionar problemas de alta latência no meu Application Load Balancer?
Estou enfrentando alta latência e limite de tempo quando tento acessar aplicativos da web em execução em alvos registrados sob um Application Load Balancer. Como faço para corrigir esses problemas?
Breve descrição
As possíveis causas da alta latência em um Application Load Balancer incluem:
- Problemas de conectividade de rede
- Alta utilização de memória (RAM) em instâncias de back-end
- Alta utilização da CPU em instâncias de back-end
- Configuração incorreta do servidor web em instâncias de back-end
- Problemas com dependências de aplicativos da web em execução em instâncias de back-end, como bancos de dados externos ou buckets do Amazon Simple Storage Service (Amazon S3)
Resolução
1. Verifique se há problemas de conectividade de rede usando as etapas de solução de problemas em Solucionar problemas no Application Load Balancer.
2. Use a ferramenta curl para medir a resposta do primeiro byte e verificar se a resolução lenta do DNS está contribuindo para a latência.
curl -kso /dev/null https://www.example.com -w "==============\n\n | dnslookup: %{time_namelookup}\n | connect: %{time_connect}\n | appconnect: %{time_appconnect}\n | pretransfer: %{time_pretransfer}\n | starttransfer: %{time_starttransfer}\n | total: %{time_total}\n | size: %{size_download}\n | HTTPCode=%{http_code}\n\n"
Exemplo de saída:
| dnslookup: 0.005330 | connect: 0.006682 | appconnect: 0.026540 | pretransfer: 0.026636 | starttransfer: 0.076980 | total: 0.077111 | size: 12130 | HTTPCode=200
Execute esses testes por meio do Application Load Balancer. Em seguida, execute os testes enquanto ignora o Application Load Balancer para os alvos. Essa abordagem ajuda a isolar o componente que está induzindo a latência. Para obter mais informações sobre os recursos curl, consulte Como usar os recursos de curl.
3. Verifique a estatística Média da métrica TargetResponseTime do Amazon CloudWatch para seu Application Load Balancer. Se o valor for alto, provavelmente há um problema com as instâncias de back-end ou com os servidores de dependência de aplicativos.
4. Determine quais instâncias de back-end estão experimentando alta latência verificando as entradas do log de acesso do seu Application Load Balancer. Verifique target_processing_time para encontrar instâncias de back-end com problemas de latência. Além disso, revise os campos request_processing_time e response_processing_time para verificar eventuais problemas com o Application Load Balancer.
5. Verifique a métrica CloudWatch CPUUtilization de suas instâncias de back-end. Procure uma alta utilização da CPU ou picos na utilização da CPU. Para uma alta utilização da CPU, considere atualizar suas instâncias para um tipo de instância maior.
6. Verifique se há problemas de memória analisando os processos do Apache em suas instâncias de back-end.
Exemplo de comando:
watch -n 1 "echo -n 'Apache Processes: ' && ps -C apache2 --no-headers | wc -l && free -m"
Exemplo de saída:
Every 1.0s: echo –n 'Apache Processes: ' && ps –C apache2 –no- headers | wc -1 && free –m Apache Processes: 27 total used free shared buffers cached Mem: 8204 7445 758 0 385 4567 -/+ buffers/cache: 2402 5801 Swap: 16383 189 16194
7. Verifique a configuração MaxClient dos servidores web em suas instâncias de back-end. Essa configuração define quantas solicitações simultâneas a instância pode atender. Para casos com utilização adequada de memória e CPU com alta latência, considere aumentar o valor de MaxClient.
Compare o número de processos gerados pelo Apache (httpd) à configuração MaxClient. Se o número de processos do Apache frequentemente atingir o valor MaxClient, considere aumentar o valor.
[root@ip-192.0.2.0 conf]# ps aux | grep httpd | wc -l 15
<IfModule prefork.c> StartServers 10 MinSpareServers 5 MaxSpareServers 10 ServerLimit 15 MaxClients 15 MaxRequestsPerChild 4000 </IfModule>
8. Verifique as dependências de suas instâncias de back-end que possam estar causando problemas de latência. As dependências podem incluir bancos de dados compartilhados ou recursos externos (como buckets do Amazon S3). As dependências também podem incluir conexões de recursos externos, como instâncias de conversão de endereços de rede (NAT), serviços web remotos ou servidores proxy.
9. Use as seguintes ferramentas Linux para identificar gargalos de desempenho no servidor.
uptime – Mostra as médias de carga para ajudar a determinar o número de tarefas (processos) aguardando execução. Em sistemas Linux, esse número inclui processos aguardando execução na CPU, bem como processos bloqueados em E/S ininterrupta (geralmente E/S de disco). Esses dados fornecem uma visão de alto nível da carga (ou demanda) de recursos que deve ser interpretada usando outras ferramentas. Quando as médias de carga do Linux aumentam, há uma demanda maior por recursos. Para determinar quais recursos estão em maior demanda, você deve usar outras métricas. Por exemplo, para CPUs, você pode usar mpstat -P ALL 1 para medir a utilização por CPU ou top ou pidstat 1 para medir a utilização da CPU por processo.
mpstat -P ALL 1 – Mostra divisões de tempo de CPU por CPU, que você pode usar para verificar se há um desequilíbrio. Uma única CPU ativa pode ser evidência de um aplicativo de thread único.
**pidstat 1 ** – Mostra a utilização da CPU por processo e imprime um resumo contínuo que é útil para observar padrões ao longo do tempo.
dmesg | tail – Mostra as últimas 10 mensagens do sistema, se houver alguma. Procure erros que possam causar problemas de desempenho.
iostat -xz 1 – Mostra a carga de trabalho aplicada aos dispositivos de bloco (discos) e o desempenho resultante.
free -m – Mostra a quantidade de memória livre. Verifique se esses números não têm tamanho próximo de zero, o que pode levar a uma maior E/S do disco (confirme usando iostat) e à diminuição do desempenho.
sar -n DEV 1 – Mostra a taxa de transferência da interface de rede (rxkB/s e txkB/s) como uma medida da carga de trabalho. Verifique se algum limite foi atingido.
sar -n TCP, ETCP 1 – Mostra as principais métricas de TCP, incluindo: active/s (número de conexões TCP iniciadas localmente por segundo), passive/s (número de conexões TCP iniciadas remotamente por segundo) e retrans/s (número de retransmissões de TCP por segundo).
**iftop ** – Mostra as conexões entre seu servidor e um endereço IP remoto que estão consumindo mais largura de banda. n iftop está disponível em um pacote com o mesmo nome em distribuições baseadas em Red Hat e Debian. No entanto, com distribuições baseadas em Red Hat, você pode encontrar n iftop em um repositório de terceiros.
Conteúdo relevante
- AWS OFICIALAtualizada há 3 anos
- AWS OFICIALAtualizada há um ano
- AWS OFICIALAtualizada há um ano
- AWS OFICIALAtualizada há 2 anos