Problème de latence de l'ELB d'AWS

UNITÉ CENTRALE utilisation (%) n'est pas la clé, la clé est le CPU moyenne de la charge (file d'attente) et les métriques de réseau, les métriques d'Apache, les tampons, etc. Les équilibreurs de charge sont des dispositifs très simples. Les problèmes liés à l'implication des équilibreurs de charge dans l'architecture ne sont généralement pas liés aux équilibreurs de charge, mais à la nature du fonctionnement des autres éléments.

Pour déterminer où se situe le problème, il convient de suivre les étapes suivantes :

• Vérifiez si apache répond aux requêtes locales, si ce n'est pas le cas, le problème n'est PAS l'ELB.
• Vérifier l'état des travailleurs d'Apache (i.e. mod_status), ajuster les paramètres MPM en conséquence.
• Vérifiez la charge moyenne de l'unité centrale, si la charge moyenne dépasse le nombre d'unités centrales et si le nombre d'unités centrales augmente, vous avez un problème avec l'IO.
• Vérifiez si la persistance de la connexion est activée et si elle est vraiment nécessaire, si vous utilisez vraiment des sessions sur des serveurs web qui ont besoin d'accéder à la même instance web.
• Vérifiez les paramètres de keepalive pour apache, désactivez-les ou définissez une valeur de timeout très faible.
• Vérifiez si iptables est activé sur l'instance et si les paramètres du noyau nf_conntrack_max et nf_conntrack_count sont configurés avec des valeurs plus élevées. Si vous n'en avez pas besoin, désactivez les modules et ne les chargez pas du tout.
• Test de stress d'instances uniques avec des requêtes http (hint : ab, jmeter)

• Vérifier et ajuster les paramètres du noyau en conséquence :

  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

Apache ne répond plus après cela ? Ce n'est pas du tout la faute d'ELB.