Les retards intermittents de Tomcat, ne répondent pas, s'accrochent

J'ai essayé de repérer la cause des ralentissements intermittents de notre server Tomcat. Nous obtenons les ralentissements plusieurs fois par semaine, où Tomcat cessera de répondre ou prend plusieurs minutes pour traiter les requêtes, et les charges de l'ordinateur sur la boîte (Linux), comme le montre le time de disponibilité, augmentent généralement entre 1-2 et plus de 30. Puis les choses progressivement se déroulent et tout revient à la normale après peut-être 10 minutes environ.

Nous utilisons Apache comme front end et Postgres pour notre database. J'ai creusé les journaux pour essayer de comprendre ce qui pourrait causer le problème. Je n'ai pas remarqué d'augmentation évidente de la request autour des time des ralentissements.

Ce que j'ai trouvé, c'est que, à plusieurs resockets, juste avant le ralentissement, Tomcat semble s'endormir pendant environ trois minutes et demi. Il n'y a pas d'inputs dans ses journaux pendant cette période et aucune requête de Tomcat vers la database. Après sa petite sieste, Tomcat se réveille et commence à essayer de traiter en profondeur tout ce qui a été sauvegardé en attendant, ce qui a entraîné de lourdes charges de database et de processeurs et des time de réponse lents.

Afin d'essayer de comprendre ce que fait Tomcat pendant sa sieste, j'ai configuré un script pour surveiller son journal et envoyer un signal kill -3 pour get une décharge de thread s'il n'y avait plus d'activité dans le journal pendant trois minutes. Malheureusement, le signal ne réveille pas Tomcat, de sorte que le déversement de fil ne se produit qu'après avoir réveillé de lui-même et a repris le traitement.

Apache et Postgres sont apparemment encore éveillés et actifs pendant les trois minutes et demi – leurs journaux montrent une activité non-Tomcat qui se poursuit pendant ces périodes.

Notre version Tomcat est 5.0.28.

Des pensées, des suggestions? Je suis assez nouveau pour travailler avec Tomcat, alors n'assumez pas beaucoup de connaissances.


Après avoir activé la collecte détaillée des ordures par suggestion d'Alex, j'ai capturé quelques occurrences du problème et j'ai constaté qu'une GC complète était responsable, prenant plus de 200 secondes dans les deux cas, par exemple:

04:21:55.648491500 [GC 1035796K->933637K(1041984K), 0.3407580 secs] 04:21:56.012832500 [Full GC[Unloading class sun.reflect.GeneratedMethodAccessor633] 04:22:38.003920500 [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor39] 04:22:38.004051500 [Unloading class sun.reflect.GeneratedConstructorAccessor102] 04:22:38.004392500 [Unloading class sun.reflect.GeneratedConstructorAccessor98] 04:22:38.004533500 [Unloading class sun.reflect.GeneratedSerializationConstructorAccessor40] 04:22:38.004716500 [Unloading class sun.reflect.GeneratedMethodAccessor634] 04:22:38.004808500 [Unloading class sun.reflect.GeneratedConstructorAccessor90] 04:22:38.004889500 [Unloading class sun.reflect.GeneratedConstructorAccessor95] 04:22:38.005044500 [Unloading class sun.reflect.GeneratedMethodAccessor632] 04:25:18.688916500 933637K->154281K(1041984K), 202.6760940 secs] 

Maintenant, j'ai juste besoin de comprendre comment régler les choses pour éviter cela. (Suggestions bienvenues.)

Merci pour l'aide Alex et Mainguy.

3 Solutions collect form web for “Les retards intermittents de Tomcat, ne répondent pas, s'accrochent”

La première étape, comme indiqué ci-dessus, consiste à modifier le script de démarrage Tomcat pour append
-verbose: gc -XX: + PrintGCTimeStamps -XX: + PrintGCDetails

Lorsque vous avez votre ralentissement, cherchez des choses dans catalina.out comme "FullGC" ou plusieurs GC …

Je remarquerais que si vous ne l'avez pas déjà fait, bousculer la taille du tas de tomcat à quelque part autour de 1/2 à 3/4 de memory disponible en supposant que cette boîte JUST fonctionne Tomcat. Par exemple, pour configurer le tas maximum à 768 mégaoctets, vous appendiez: -Xmx768M à JAVA_OPTS

Si vous utilisez ubuntu 10.04, ces parameters seraient généralement situés dans / etc / default / tomcat6.

Nous avons eu cela quand un bon morceau de la memory de la génération "tenure" du tas de Java a été échangé sur le disque car il s'agit d'ordures et n'a pas été utilisé depuis longtime. Lorsqu'une collection complète est nécessaire, cette memory doit être remplacée.

Dans ce cas, votre réponse est quelque peu intuitive: reduit la taille du tas Java ou détermine ce que d'autres choses utilisent de la RAM qui cause l'échange. Dans notre cas, certains travaux par lots nocturnes ont utilisé un tas de RAM, ce qui a amené l'ancienne génération à être transférée sur le disque. Donc, alors, le premier GC complet nécessaire au lendemain matin a pris FOREVER (180+ secondes, tout comme vous le voyez).

Vous pouvez également essayer le collecteur de balayage de marque concurrente, ce qui réduit les time de GC complets en effectuant une grande partie du travail en parallèle. C'est la meilleure documentation que j'ai vue; Il existe également de bons blogs Sun sur le sujet: http://www.oracle.com/technetwork/java/gc-tuning-5-138395.html

Essayez d'activer la garbage collection verbales et de voir s'il s'agit d'une pause de garbage collection. Je suppose qu'un énorme tas, beaucoup d'allocation d'object et d'échange peuvent causer une longue pause, mais cela semble assez inhabituel.

  • Port AJP occupé au hasard lors du redémarrage du server
  • Tunnel HTTP via HTTPS utilisant Apache
  • Comment lire l'échelle du système de surveillance de Munin, tomcat accède par graphique du jour
  • Alternatives à Apache
  • comment configurer tomcat6 pour ubuntu
  • Temps de téléchargement lent sur le server TomEE sur l'instance AWS EC2 Windows Server 2008
  • Quelle est une bonne configuration pour l'exécution d'applications Java et PHP avec SSL sur le même server?
  • Amélioration du dossier IOps élevé (Tomcat et Vmware)
  • Comment accéder à un file ou dossier simple à partir du dossier Tomcat webapps
  • Déploiement d'une application Java sur Tomcat 7 avec version contextuelle
  • Tomcat ne sert à rien
  • Les astuces du serveur de linux et windows, tels que ubuntu, centos, apache, nginx, debian et des sujets de rĂ©seau.