Service AWS ELB Apache2 503 non disponible: le serveur dorsal est saturé

Cela fait environ deux ans que nous exploitons quelques sites Web sur l'infrastructure AWS d'Amazon. Depuis environ deux jours, le serveur Web a commencé à tomber en panne une ou deux fois par jour avec la seule erreur que je puisse trouver:

HTTP/1.1 503 Service Unavailable: Back-end server is at capacity

CloudWatch ne déclenche aucune alarme (CPU / disque IO / DB Conn). J'ai essayé d'aller sur le site via l'IP élastique pour sauter l'ELB et j'ai obtenu ceci:

HTTP request sent, awaiting response... Read error (Connection reset by peer) in headers. Retrying.

Je ne vois rien d’extraordinaire dans les journaux d’Apache et je vérifie qu’ils étaient correctement pivotés. Je n'ai aucun problème à accéder à la machine lorsqu'elle est "arrêtée" via SSH et en regardant la liste des processus, 151 processus apache2 me paraissent normaux. Redémarrer Apache résout temporairement le problème. Cette machine fonctionne comme un serveur Web derrière un ELB. Toutes les suggestions seraient grandement appréciées.

Utilisation moyenne du processeur: 7.45%, Minimum: 0.00%, Maximum: 25.82%

Utilisation de la mémoire Moyenne: 11,04%, Minimum: 8,76%, Maximum: 13,84%

Moyenne d'utilisation de l'échange: N / A, Minimum: N / A, Maximum: N / A

Utilisation de l'espace disque pour / dev / xvda1 monté sur / Moyenne: 62,18%, Minimum: 53,39%, Maximum: 65,49%

Permettez-moi de préciser. Je pense que le problème concerne l'instance individuelle EC2 et non l'ELB. Je ne voulais tout simplement pas l'exclure, même si je ne pouvais pas atteindre l'élasticité IP. Je soupçonne que ELB ne fait que renvoyer les résultats de la frappe de l'instance EC2 réelle.

Mise à jour: 2014-08-26 J'aurais dû mettre à jour cette information plus tôt, mais la "solution" consistait à prendre un instantané de la "mauvaise" instance et à démarrer l'AMI résultante. Il n'a pas diminué depuis. J'ai consulté le bilan de santé alors que je rencontrais encore des problèmes et je pouvais accéder à la page du bilan de santé ( curl http://localhost/page.html), même lorsque le problème de la capacité de l'équilibreur de charge me posait problème. Je ne suis pas convaincu qu'il s'agisse d'un problème de santé, mais comme personne, y compris Amazon, ne peut fournir une meilleure réponse, je le marque comme la réponse. Merci.

Mise à jour: 2015-05-06 Je pensais revenir ici et dire qu'une partie du problème que je crois fermement maintenant concerne les paramètres de bilan de santé. Je ne veux pas exclure qu'ils soient un problème avec l'AMI, car il s'est nettement amélioré après le lancement de l'AMI de remplacement, mais j'ai découvert que nos contrôles de santé étaient différents pour chaque équilibreur de charge et que celui qui rencontrait le plus de problèmes avait un seuil très agressif malsain et un délai de réponse. Notre trafic a tendance à augmenter de façon imprévisible et je pense qu'entre les paramètres de bilan de santé agressifs et les pics de trafic, c'était une tempête parfaite.

Vous obtiendrez un "Le serveur principal est à pleine capacité" lorsque l'équilibreur de charge ELB effectue ses contrôles d'intégrité et reçoit une "page introuvable" (ou une autre erreur simple) en raison d'une mauvaise configuration (généralement avec l'hôte NameVirtual).

Essayez de créer un répertoire des fichiers journaux à l’aide de l’agent utilisateur "ELB-HealthChecker". par exemple

grep ELB-HealthChecker  /var/log/httpd/*

Cela vous donnera généralement une erreur 4x ou 5x qui est facilement corrigée. Par exemple, Inondation, MaxClients, etc. donne beaucoup trop de crédit au problème.

FYI Amazon: Pourquoi ne pas afficher la réponse renvoyée par la demande? Même un code de statut aiderait.

Je viens de rencontrer ce problème moi-même. Amazon ELB renverra cette erreur s'il n'y a pas d'instances saines. Nos sites ont été mal configurés et la vérification de l'état de santé de la bande ELB a échoué, ce qui a amené ELB à supprimer la rotation des deux serveurs. Avec zéro sites sains, ELB a renvoyé le service 503 indisponible: le serveur principal est à pleine capacité.

[EDIT après avoir mieux compris la question] N'ayant aucune expérience de l'ELB, je pense toujours que cela ressemble étrangement à l'erreur 503 qui peut être émise quand Apache fait face à un Tomcat et inonde la connexion.

En conséquence, si Apache fournit plus de demandes de connexion que le back-end ne peut en traiter, les files d'attente d'entrée du back-end se rempliront jusqu'à ce qu'il ne soit plus possible d'accepter de connexions. Lorsque cela se produit, les files d'attente de sortie correspondantes d'Apache commencent à se remplir. Lorsque les files d'attente sont pleines, Apache lance un 503. Il s'ensuivrait que la même chose pourrait se produire lorsque Apache est le serveur principal, et que l'interface fournit les données à un rythme tel que les files d'attente se remplissent.

La solution (hypothétique) consiste à dimensionner les connecteurs d’entrée des connecteurs d’arrière et de sortie du client. Cela se transforme en un acte d'équilibrage entre le niveau d'inondation prévu et la RAM disponible des ordinateurs impliqués.

Pour ce faire, vérifiez les paramètres de maxclients et surveillez les travailleurs occupés dans Apache (mod_status.). Faites la même chose, si possible, avec tout type d’ELB correspondant au backlog du connecteur Tomcats, à maxthreads, etc. En résumé, examinez tout ce qui concerne les files d’attaque d’Apache et les files d’attente de sortie de ELB.

Bien que je comprenne parfaitement qu’il n’est pas directement applicable, ce lien contient un guide de dimensionnement du connecteur Apache. Vous devez rechercher les détails techniques de la file d’attente ELB, puis effectuer le calcul: http://www.cubrid.org/blog/dev-platform/maxclients-in-ap-ap-and-its-effect-on-tomcat-during- full-gc /

Comme indiqué dans le commentaire ci-dessous, pour surcharger le connecteur Apache, un pic de trafic n'est pas la seule possibilité. Si certaines demandes sont traitées plus lentement que d’autres, une proportion plus élevée de celles-ci peut également entraîner le remplissage des files d’attente de connecteurs. C'était vrai dans mon cas.

De plus, lorsque cela m'est arrivé, j'ai été déconcerté de devoir redémarrer le service Apache afin de ne plus être servi par 503: s. Attendre simplement que l’inondation du connecteur ne soit pas suffisante. Je n'ai jamais compris cela, mais on peut supposer qu'Apache sert de son cache peut-être?

Après avoir augmenté le nombre de travailleurs et les paramètres correspondants max-clients avant utilisation (il s’agissait d’Apache multithread sous Windows contenant quelques directives pour les files d’attente, si je me souviens bien), le problème de 503 a disparu. En fait, je n'ai pas fait le calcul, mais j'ai juste modifié les valeurs jusqu'à ce que je puisse observer une marge importante par rapport à la consommation maximale des ressources de la file d'attente. Je laisse tomber à cela.

J'espère que cela vous a aidé.

vous pouvez augmenter les valeurs du vérificateur de santé elb, de sorte qu’une seule réponse lente ne tire pas un serveur d’elb. Il est préférable que quelques utilisateurs obtiennent un service indisponible, que le site soit désactivé pour tout le monde.

EDIT: Nous pouvons nous échapper sans préchauffage de la mémoire cache en augmentant le délai de vérification de l'état de santé à 25 secondes ...... après 1 à 2 minutes ... le site est réactif comme l'enfer.

EDIT :: lancez juste un paquet de demandes à la demande, et quand vos outils de surveillance montrent à votre direction à quelle vitesse vous êtes, alors il suffit de prépayer RI amazon: P

EDIT: il est possible, une seule instance enregistrée elb backend ne suffit pas. lancez-en un peu plus et enregistrez-les auprès de elb, ce qui vous aidera à mieux cerner votre problème

Il a quelques années de retard, mais j'espère que cela aidera quelqu'un.

Je voyais cette erreur lorsque l'instance derrière ELB n'avait pas d'adresse IP publique appropriée attribuée. J'avais besoin de créer manuellement une adresse IP Elastic et de l'associer à l'instance, après quoi l'ELB l'a capturée presque instantanément.