18 votes

Apache Tomcat s'étouffe après 300 connexions

Nous avons un serveur web apache devant Tomcat hébergé sur EC2, le type d'instance est extra large avec 34GB de mémoire.

Notre application traite avec de nombreux services Web externes et nous avons un service Web externe très mauvais qui prend presque 300 secondes pour répondre aux demandes pendant les heures de pointe.

Pendant les heures de pointe, le serveur s'étouffe à environ 300 processus httpd. ps -ef | grep httpd | wc -l =300

J'ai cherché sur Google et trouvé de nombreuses suggestions mais rien ne semble fonctionner. Voici quelques configurations que j'ai faites et qui sont directement tirées de ressources en ligne.

J'ai augmenté les limites de connexion maximale et de clients maximaux dans apache et tomcat. Voici les détails de la configuration :

//apache

   <IfModule prefork.c>
    StartServers 100
    MinSpareServers 10
    MaxSpareServers 10
    ServerLimit 50000
    MaxClients 50000
    MaxRequestsPerChild 2000
    </IfModule>

//tomcat

    <Connector port="8080" protocol="org.apache.coyote.http11.Http11NioProtocol"
           connectionTimeout="600000"
           redirectPort="8443"
           enableLookups="false" maxThreads="1500"
           compressableMimeType="text/html,text/xml,text/plain,text/css,application/x-javascript,text/vnd.wap.wml,text/vnd.wap.wmlscript,application/xhtml+xml,application/xml-dtd,application/xslt+xml"
           compression="on"/>

//Sysctl.conf

 net.ipv4.tcp_tw_reuse=1
 net.ipv4.tcp_tw_recycle=1
 fs.file-max = 5049800
 vm.min_free_kbytes = 204800
 vm.page-cluster = 20
 vm.swappiness = 90
 net.ipv4.tcp_rfc1337=1
 net.ipv4.tcp_max_orphans = 65536
 net.ipv4.ip_local_port_range = 5000 65000
 net.core.somaxconn = 1024

J'ai essayé de nombreuses suggestions mais en vain comment résoudre ce problème ? Je suis sûr que le serveur m2xlarge devrait servir plus de requêtes que 300, il se peut que je me trompe dans ma configuration

Le serveur ne s'arrête que pendant les heures de pointe et lorsqu'il y a 300 demandes simultanées qui attendent la réponse du service Web [avec un retard de 300 secondes].

Je surveillais les connexions tcp avec netstat.

J'ai trouvé environ 1000 connexions dans l'état TIME_WAIT, aucune idée de ce que cela signifie en termes de performance, je suis sûr que cela doit ajouter au problème.

Sortie du TOP

 8902  root      25   0 19.6g 3.0g  12m S  3.3  8.8  13:35.77 java
 24907 membase   25   0  753m 634m 2528 S  2.7  1.8 285:18.88 beam.smp
 24999 membase   15   0  266m 121m 3160 S  0.7  0.3  51:30.37 memcached
 27578 apache    15   0  230m 6300 1536 S  0.7  0.0   0:00.03 httpd
 28551 root      15   0 11124 1492  892 R  0.3  0.0   0:00.25 top

 Output of free -m
 total       used       free     shared    buffers    cached
 35007       8470       26536    0          1         61
 8407        26599
 15999       15         15984

 output of iostat
 avg-cpu:  %user   %nice %system %iowait  %steal   %idle
      26.21    0.00    0.48    0.13    0.02   73.15

Device:            tps   Blk_read/s   Blk_wrtn/s   Blk_read   Blk_wrtn
sda1             14.36         4.77       329.37    9005402  622367592
sdb               0.00         0.00         0.00       1210         48

En outre, aux heures de pointe, il y a environ 10-15k connexions tcp au serveur membase [local].

QUELQUES ERREURS DANS LE LOG MODJK, j'espère que cela va éclairer le problème

[Wed Jul 11 14:39:10.853 2012] [8365:46912560456400] [error]         ajp_send_request::jk_ajp_common.c (1630): (tom2) connecting to backend failed. Tomcat is probably not started or is listening on the wrong port (errno=110)
[Wed Jul 11 14:39:18.627 2012] [8322:46912560456400] [error] ajp_send_request::jk_ajp_common.c (1630): (tom2) connecting to backend failed. Tomcat is probably not started or is listening on the wrong port (errno=110)
[Wed Jul 11 14:39:21.358 2012] [8351:46912560456400] [error] ajp_get_reply::jk_ajp_common.c (2118): (tom1) Tomcat is down or refused connection. No response has been sent to the client (yet)
[Wed Jul 11 14:39:22.640 2012] [8348:46912560456400] [error] ajp_get_reply::jk_ajp_common.c (2118): (tom1) Tomcat is down or refused connection. No response has been sent to the client (yet)

~

Worker.properties
workers.tomcat_home=/usr/local/tomcat/
worker.list=loadbalancer
worker.tom1.port=8009
worker.tom1.host=localhost
worker.tom1.type=ajp13
worker.tom1.socket_keepalive=True
worker.tom1.connection_pool_timeout=600
worker.tom2.port=8109
worker.tom2.host=localhost
worker.tom2.type=ajp13
worker.tom2.socket_keepalive=True
worker.tom2.connection_pool_timeout=600
worker.loadbalancer.type=lb
worker.loadbalancer.balanced_workers=tom1,tom2
worker.loadbalancer.sticky_session=True
worker.tom1.lbfactor=1
worker.tom1.socket_timeout=600
worker.tom2.lbfactor=1
worker.tom2.socket_timeout=600

//Solved

Merci à tous pour vos précieuses suggestions J'ai oublié les paramètres maxThreads pour le connecteur AJP 1.3 Maintenant tout semble sous contrôle.

Je commencerais aussi à regarder les serveurs basés sur le pair comme nginx.

13voto

user13993 Points 257

Avez-vous augmenté maxThreads dans le connecteur AJP 1.3 sur le port 8009 ?

7voto

Alex Points 7759

Envisagez la mise en place d'un serveur web asynchrone par procuration comme nginx o lighttpd devant Apache. Apache sert le contenu de manière synchrone, de sorte que les travailleurs sont bloqués jusqu'à ce que les clients téléchargent le contenu généré en entier (plus de détails ici ). La mise en place d'un proxy asynchrone (non bloquant) améliore généralement la situation de façon spectaculaire (j'ai pu réduire le nombre de travailleurs Apache s'exécutant simultanément de 30 à 3-5 en utilisant nginx comme proxy frontal).

5voto

Matthew Ife Points 22370

Je soupçonne que votre problème se situe dans tomcat et non dans apache, d'après les journaux que vous avez montrés en tout cas. Lorsque vous obtenez 'error 110' en essayant de vous reconnecter à tomcat, cela indique que vous avez une file d'attente de connexions en attente d'être servies qui ne peuvent plus s'insérer dans le backlog d'écoute configuré pour le socket d'écoute dans tomcat.

From the listen manpage:
   The  backlog  parameter defines the maximum length the queue of pending 
   connections may grow to.  If a connection request arrives with
   the queue full the client may receive an error with an indication
   of ECONNREFUSED or, if the underlying protocol supports  
   retransmission, the request may be ignored so that retries succeed.

Si je devais deviner, je soupçonnerais que la grande majorité des requêtes HTTP lorsque le serveur est "étouffé" est bloquée en attendant quelque chose en retour de tomcat. Je parie que si vous essayez de récupérer du contenu statique qui est directement servi par Apache (plutôt que d'être proxié à Tomcat), cela fonctionnerait même lorsque le serveur est normalement "étouffé".

Je ne suis pas familier avec tomcat malheureusement, mais y a-t-il un moyen de manipuler les paramètres de concurrence de cette place ?

Oh, et vous devriez également envisager la possibilité que ce soit les services du réseau externe qui limitent le nombre de connexions que vous pouvez établir. il fait pour vous Ainsi, la quantité de manipulation de la concurrence que vous effectuez sur votre côté frontal ne fait aucune différence si pratiquement toutes les connexions que vous établissez reposent sur une réponse de services Web externes.

Dans l'un de vos commentaires, vous avez mentionné que les données deviennent périmées après 2 minutes. Je vous suggère de mettre en cache la réponse que vous obtenez de ce service pendant deux minutes afin de réduire le nombre de connexions simultanées au service Web externe.

2voto

cyphun Points 53

La première étape pour résoudre ce problème est d'activer la fonction d'Apache mod_status et d'étudier son rapport - tant que vous n'avez pas fait cela, vous marchez en fait à l'aveuglette. Ce n'est pas vertueux. ;-)

La deuxième chose à mentionner (je n'aime pas qu'on me donne des réponses à des questions que je n'ai pas posées, mais...) est l'utilisation de serveurs frontaux plus efficaces et spéciaux, tels que nginx .

Aussi, avez-vous exactement restart apache, ou simplement graceful ly rechargé il ? :)

1voto

adaptr Points 16431

Pour toute sorte de déploiement d'entreprise, le MPM prefork est à peu près le pire choix que vous puissiez faire : il engloutit des ressources comme personne et le redémarrage des threads prend une éternité par rapport aux autres MPM.

Au moins, passez à la travailleur MPM (apache 2.2 et plus) ou - mieux encore - mettez à niveau vers la version stable actuelle 2.4.2 avec sa version par défaut. événement MPM.

Ces deux systèmes permettent de gérer facilement des milliers de connexions simultanées avec très peu de frais généraux.

SistemesEz.com

SystemesEZ est une communauté de sysadmins où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres sysadmins, poser vos propres questions ou résoudre celles des autres.

Powered by:

X