Passer au contenu

Comment puis-je résoudre les problèmes de latence élevée sur mon Application Load Balancer dans Elastic Load Balancing ?

Lecture de 7 minute(s)
0

Je souhaite résoudre les problèmes de latence élevée sur mon Application Load Balancer dans Elastic Load Balancing (ELB).

Brève description

Les causes d'une latence élevée sur un Application Load Balancer sont les suivantes :

  • Problèmes de connectivité ou de congestion du réseau
  • Utilisation élevée de la mémoire (RAM) sur les instances dorsales
  • Utilisation élevée du processeur sur les instances dorsales
  • Configurations de serveur Web incorrectes sur les instances dorsales
  • Problèmes liés aux dépendances des applications Web qui s'exécutent sur les instances dorsales
  • Distance géographique importante entre les clients ou les cibles sur site et l'Application Load Balancer

Résolution

Pour résoudre les problèmes de latence élevée sur votre Application Load Balancer, effectuez les opérations suivantes :

  • Vérifiez les problèmes de connectivité réseau. Pour plus d'informations, consultez la section Résoudre les problèmes liés à vos Application Load Balancers.

  • Mesurez la réponse du premier octet et vérifiez l’existence d’une résolution DNS lente susceptible de provoquer une latence :

    curl -kso /dev/null -w "\n===============\n
    | DNS lookup: %{time_namelookup}\n
    | Connect: %{time_connect}\n
    | App connect: %{time_appconnect}\n
    | Pre-transfer: %{time_pretransfer}\n
    | Start transfer: %{time_starttransfer}\n
    | Total: %{time_total}\n
    | HTTP Code: %{http_code}\n===============\n" https://example.com/

    Exemple de sortie :

    ===============
    | DNS lookup: 0.002346
    | Connect: 0.003080
    | App connect: 0.008422
    | Pre-transfer: 0.008587
    | Start transfer: 0.050238
    | Total: 0.057486
    | HTTP Code: 200
    ===============

    Remarque : Pour isoler la cause de la latence, effectuez l'étape précédente avec votre Application Load Balancer, puis recommencez l'étape et ignorez votre Application Load Balancer. Pour plus d'informations, consultez la page de manuel de curl sur le site Web de curl.

  • Consultez la statistique Moyenne de la métrique Amazon CloudWatch TargetResponseTime pour votre Application Load Balancer. Si la valeur est élevée, cela signifie qu’un problème s’est produit sur les instances dorsales ou les serveurs de dépendance des applications. Pour en savoir plus, consultez la section Comment puis-je résoudre le problème d'une augmentation de la métrique TargetResponseTime pour un Application Load Balancer ?

  • Pour identifier les instances dorsales présentant une latence élevée, consultez les entrées du journal d'accès de votre Application Load Balancer.

  • Pour identifier les instances dorsales présentant des problèmes de latence, vérifiez le champ target_processing_time pendant une période anormalement longue.

  • Pour vérifier les problèmes liés à l'Application Load Balancer, examinez les champs request_processing_time et response_processing_time pour détecter des périodes anormalement longues.

    Exemple d'entrée de journal :

    http 2024-04-01T22:23:00.765170Z app/example-loadbalancer/50dc6c495c0c9188
    192.168.131.39:2817 10.0.0.1:80 0.001 12.401 0.001 200 200 34 366
    "GET http://www.example.com:80/ HTTP/1.1" "curl/7.46.0" - -
    arn:aws:elasticloadbalancing:us-east-2:123456789012:targetgroup/example-targets/73e2d6bc24d8a067
    "Root=1-58337262-36d228ad5d99923122bbe354" "-" "-"
    0 2024-04-01T22:22:48.364000Z "forward" "-" "-" "10.0.0.1:80" "200" "-" "-"

    Remarque : L’exemple d’entrée de journal précédent indique que la valeur de request_processing_time est 0,001, que la valeur de target_processing_time est 12,401 et que la valeur de response_processing_time est 0,001. La valeur de target_processing_time indique une période plus longue que la normale et que la cible Application Load Balancer a provoqué une latence. Pour en savoir plus, consultez la section Syntaxe.

  • Pour identifier une utilisation élevée du processeur ou des pics d'utilisation du processeur, consultez la métrique CPUUtilization CloudWatch de vos instances dorsales. Pour résoudre une utilisation élevée du processeur, mettez à niveau vos instances vers un type d'instance de plus grande capacité.

  • Pour examiner les processus Apache de votre backend et vérifier l’existence éventuelle de problèmes de mémoire, exécutez la commande suivante :

    watch -n 1 "echo -n 'Apache Processes: ' && ps -C apache2 --no-headers | wc -l && free -m"

    Exemple de sortie :

    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
  • Pour vérifier le nombre de requêtes simultanées que votre instance peut traiter, consultez le paramètre MaxClient pour les serveurs Web de vos instances dorsales. Si votre instance dispose d'une quantité appropriée de mémoire et d'utilisation du processeur et présente toujours une latence élevée, augmentez la valeur de MaxClient.

  • Comparez le nombre de processus générés par Apache (httpd) à la valeur de MaxClient. Si le nombre de processus Apache atteint fréquemment la valeur MaxClient, augmentez-la.****

    Exemple de commande :

    [root@ip-192.0.2.0 conf]# ps aux | grep httpd | wc -l 15

    Exemple de sortie :

    <IfModule prefork.c>StartServers         10
    MinSpareServers      5
    MaxSpareServers      10
    ServerLimit          15
    MaxClients           15
    MaxRequestsPerChild  4000
    </IfModule>

Vérifier les dépendances du backend

Vérifiez l’existence de dépendances à l'origine de problèmes de latence sur vos instances dorsales. Parmi les dépendances, citons les compartiments Amazon Simple Storage Service (Amazon S3), les instances de traduction d'adresses réseau (NAT) ou les serveurs proxy et les services Web à distance.

Utiliser les outils Linux pour identifier les goulots d'étranglement de performances

Pour identifier les problèmes de performances sur le serveur, utilisez les commandes Linux suivantes :

  • Exécutez la commande uptime pour vérifier si les moyennes de charge du système sont élevées en raison d'une contention de ressources. La sortie affiche les moyennes de charge du système qui correspondent au nombre de tâches en attente d'exécution ou bloquées sur les I/O.
  • La commande mpstat -P ALL 1 affiche une répartition de l'utilisation du processeur pour chaque cœur. Exécutez la commande pour déterminer un déséquilibre d’utilisation, par exemple un cœur unique qui gère la plus grande partie du travail dans une application monothread.
  • Pour identifier les processus et modèles gourmands en ressources au fil du temps, exécutez la commande pidstat 1. La sortie indique l'utilisation du processeur en temps réel par processus.
  • Exécutez la commande dmesg | tail pour identifier les événements récents au niveau du système susceptibles d'affecter les performances. La sortie présente les 10 derniers messages du système.
  • Pour identifier les opérations de lecture ou d'écriture élevées ou les performances lentes du disque, exécutez la commande iostat -xz 1. La sortie indique les métriques et l'utilisation des I/O du disque.
  • Exécutez la commande free -m pour afficher la mémoire système disponible. Si la mémoire disponible est faible, le système peut s'appuyer sur un échange qui augmente les I/O du disque et la latence.
  • Pour identifier la saturation de la bande passante, exécutez la commande sar -n DEV 1 tool. La sortie indique le débit de l'interface réseau qui inclut le trafic reçu (RxKb/s) et transmis (TxKb/s).
  • Exécutez sar -n TCP,ETCP 1 pour afficher les principales métriques TCP suivantes qui vous aident à déterminer les problèmes de connexion :
    La métrique active/s est le nombre de connexions TCP initiées localement par seconde.
    La métrique passive/s est le nombre de connexions TCP initiées à distance par seconde.
    La métrique retrans/s est le nombre de retransmissions TCP par seconde. Lorsque cette métrique est élevée, vous pouvez être confronté à une perte de paquets ou à une congestion.
  • Pour identifier ce qui utilise le plus de bande passante sur le réseau, exécutez la commande iftop. La sortie indique l'utilisation active de la bande passante pour chaque connexion en temps réel.
  • La commande niftop est une variante iftop qui peut être disponible via des référentiels tiers sur Red Hat Enterprise Linux (RHEL) et des distributions basées sur Debian. Si iftop n'est pas préinstallé sur votre système, utilisez niftop.

Remarque : Selon votre distribution Linux, vous devrez peut-être installer manuellement certaines des commandes précédentes.

AWS OFFICIELA mis à jour il y a un an