Problema de latência do AWS ELB

Question

Eu tenho duas máquinas EC2 c3.2xlarge com ambiente Ubuntu tanto em us-west-2a AZ. Ambas contém o mesmo código com o banco de dados mySQL do AWS RDS (db.r3.2xlarge). Ambas as instâncias são adicionadas a um ELB. Ambos têm um cron programado que é executado duas vezes por dia.

O ELB foi configurado para disparar o alarme quando o limite ultrapassar 5.0. A utilização da CPU de ambas as instâncias é, em média, de 30 a 50. No horário de pico, atinge 100% por um minuto ou dois e, em seguida, retorna ao normal. Mas a ELB constantemente gera um alarme três vezes por dia. No momento, as duas instâncias têm

CPU     - ~50%
Memory  - total - 14979
          used  - ~6000
          free  - ~9000
RDS CPU - ~30%
          Connections - 200 to 300 /5,000

De acordo com este link , não encontrei nada de errado com as instâncias. Mas a latência ainda atinge o pico e ambas as instâncias não respondem.

Até agora, estou apenas removendo uma das instâncias do balanceador de carga, reinicie o apache e, em seguida, carregue-o de volta e faça o mesmo para outra instância. Isso faz o trabalho perfeitamente bem e as instâncias e o ELB funcionam bem nas próximas 6 a 10 horas. Mas isso não é aceitável, uma vez que, todos os dias, duas ou três vezes, um tem que cuidar do servidor, precisa dele para reiniciar.

Preciso saber se há algo errado ou qualquer passo a ser dado para resolver esse problema.

O status do servidor Apache contém muitos desses processos (~ 200/250):

7-0 23176   1/2373/5118 C   30.95   3986    0   0.0 7.01    15.78   127.0.0.1   ip-xxx-xxx-xxx-xxx.us-west-2.comp   OPTIONS * HTTP/1.0

    

Answer 1

A utilização da CPU (%) não é a chave, a chave é média de carga (fila) e métricas de rede, métricas do apache, buffers etc. Balanceadores de carga são muito dispositivos simples, problemas, onde os LBs estão envolvidos na arquitetura, geralmente não estão relacionados aos ELBs, mas à natureza de como o resto das coisas funciona.

Para ver onde está o problema, você passa pelas seguintes etapas:

• Verifique se o apache está respondendo às solicitações locais, se não - o problema NÃO é o ELB
• Verifique os estados dos funcionários do apache (ou seja, mod_status), ajuste as configurações do MPM de acordo
• Verifique a média de carga da CPU, se a média de carga aumentar acima da contagem de CPU e o iowait aumentar - você tem problemas com IO
• Verifique se a persistência da conexão está ativada e se realmente é realmente necessária, se você realmente usa sessões em servidores da Web que exigem acesso à mesma instância da Web
• Verifique as configurações de manutenção de atividade do apache, desative-as ou defina um valor de tempo limite muito baixo
• Verifique se você tem o iptables habilitado na instância e se os parâmetros do kernel nf_conntrack_max e nf_conntrack_count estão configurados com valores mais altos. Se você não precisa - desative e não carregue módulos em todos os
• Testes de estresse de instâncias únicas com solicitações http (dica: ab, jmeter)

• Verifique e ajuste os parâmetros do kernel de acordo:

  net.core.wmem_max
  net.core.rmem_max
  net.core.netdev_max_backlog
  
  net.core.somaxconn
  net.ipv4.tcp_rmem
  net.ipv4.tcp_wmem
  net.ipv4.tcp_no_metrics_save
  net.ipv4.tcp_timestamps
  net.ipv4.tcp_fin_timeout
  net.ipv4.tcp_max_tw_buckets
  net.ipv4.tcp_tw_recycle
  net.ipv4.tcp_synack_retries
  net.ipv4.tcp_keepalive_time
  
  net.netfilter.nf_conntrack_acct
  net.netfilter.nf_conntrack_generic_timeout
  net.netfilter.nf_conntrack_tcp_timeout_syn_sent
  net.netfilter.nf_conntrack_tcp_timeout_syn_recv
  net.netfilter.nf_conntrack_tcp_timeout_established
  net.netfilter.nf_conntrack_tcp_timeout_fin_wait
  net.netfilter.nf_conntrack_tcp_timeout_close_wait
  net.netfilter.nf_conntrack_tcp_timeout_last_ack
  net.netfilter.nf_conntrack_tcp_timeout_time_wait
  net.netfilter.nf_conntrack_tcp_timeout_close
  net.netfilter.nf_conntrack_tcp_timeout_max_retrans
  net.netfilter.nf_conntrack_tcp_timeout_unacknowledged
  net.netfilter.nf_conntrack_icmp_timeout
  net.netfilter.nf_conntrack_events_retry_timeout
  net.ipv4.netfilter.ip_conntrack_generic_timeout
  net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_sent
  net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_sent2
  net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_recv
  net.ipv4.netfilter.ip_conntrack_tcp_timeout_fin_wait
  net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait
  net.ipv4.netfilter.ip_conntrack_tcp_timeout_last_ack
  net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait
  net.ipv4.netfilter.ip_conntrack_tcp_timeout_close
  net.ipv4.netfilter.ip_conntrack_tcp_timeout_max_retrans
  net.ipv4.netfilter.ip_conntrack_icmp_timeout
  net.netfilter.nf_conntrack_tcp_loose
  net.netfilter.nf_conntrack_max net.nf_conntrack_max
  net.netfilter.nf_conntrack_count
  

O Apache não está respondendo depois disso? Não é culpa da ELB.