Application Web très lente dans Tomcat 7
J'ai implémenté une application Web pour démarrer le service Tomcat qui fonctionne très rapidement, mais il faut passer des heures à ralentir (de plus en plus d'utilisateurs) (environ 15 utilisateurs environ).
Vérification de RAM statistiques d'utilisation (20%), CPU (25%)
Caractéristiques du serveur:
- RAM 8 Go
- Processeur i7
- Windows Server 2008 64 bits
- Tomcat 7
- MySql 5.0
- Struts2
- -Xms1024m
- -Xmx1024m
- PermGen = 1024
- MaxPernGen = 1024
Je n'utilise pas de serveur Web, nous publions directement sur Tomcat.
La saisie de la lenteur de minuit est toujours conservée (1 seul utilisateur connecté)
La solution que j'ai est de redémarrer le service Tomcat et le temps de réponse est encore excellent.
Y at-il quelqu'un qui a connu ce problème? Tout indice serait apprécié.
Pas assez de détails fournis. Besoin de plus d'informations :(
Utilisez htop ou top pour rechercher l'utilisation de la mémoire et du processeur par processus et par thread.
CPU
Une utilisation constante de 25% de la CPU dans un système à 4 cœurs peut indiquer qu'une application/thread monocœur exécute 100% de la CPU sur le seul cœur qu'elle peut utiliser.
Quelle application consomme le processeur?
Mémoire
20% de mémoire, c'est ~ 1,6 Go. C'est un peu plus que ce à quoi je m'attendais pour un serveur inactif exécutant uniquement Tomcat + mysql. Le -Xms1024 indique à Tomcat de préallouer 1 Go de mémoire afin de l'expliquer.
Modifiez les paramètres de Tomcat en -Xms512 et -Xmx2048. Observez l'utilisation de la mémoire de Tomcat pendant que certains utilisateurs y sont exposés. Si elle continue de croître jusqu'à atteindre 2 Go ... puis se fige, cela peut indiquer une fuite de mémoire.
Disque
Utilisez df -h pour vérifier l'utilisation du disque. Une partition complète peut rendre les problèmes que vous rencontrez.
Filesystem Size Used Avail Usage% Mounted on
/cygdrive/c 149G 149G 414M 100% /
(Si vous venez de découvrir dans cet exemple que mon ordinateur portable est à court d'espace. Vous le faites bien: D)
Les journaux
Les journaux sont géniaux. Pourtant, ils ont la mauvaise habitude de remplir le disque. Vérifiez les journaux d'utilisation du disque. Les journaux sont-ils écrits/effacés/pivotés correctement lorsque de nouveaux utilisateurs se connectent? L'effacement des journaux résout-il le problème? (copiez-les quelque part pour une analyse future avant de les effacer)
Si non. Les journaux sont encore génial. Ils ont la bonne habitude de vous aider à suivre les bogues. Vérifiez les journaux Tomcat. Vous voudrez peut-être définir le niveau de journalisation pour déboguer. Que se passe-t-il en dernier quand le site Web meurt? Un message d'erreur utile? Les connexions utilisateur sont-elles toujours reçues et acceptées par Tomcat?
Application
Je suppose que les 25% de CPU vont à Tomcat (et non à mysql). Tomcat n'échoue pas seul. L'application en cours d'exécution doit échouer. Essayez de supprimer l’application de Tomcat (vous pouvez éventuellement mettre un hello world à la place). Tomcat peut-il continuer à travailler du jour au lendemain sans votre application? C'est probablement possible, auquel cas la faute est sur l'application.
Activez la journalisation de débogage complète dans votre application et essayez de suivre le problème. Exécutez-le directement à partir d’Eclipse en mode débogage et lancez-le aux utilisateurs. Est-ce que cela échoue de la même manière?
Si oui, cliquez sur "pause" dans le débogueur Eclipse et vérifiez ce que fait l'application. Regardez le code que chaque thread exécute actuellement + sa pile d'appels. Répétez cela plusieurs fois. S'il y a une impasse, une boucle infinie ou similaire, vous pouvez le trouver de cette façon.
Si vous avez de la chance, vous avez déjà résolu le problème. Si ce n'est pas le cas, vous êtes malheureux et c'est un bug compliqué qui pourrait se trouver au plus profond de l'application. Cela peut être difficile à tracer. La détermination mènera au succès. Bonne chance =)
Pour problème lié aux performances , nous devons suivre les règles données:
- Vous pouvez égaliser et mettre l'accent sur la taille de xms et xmx pour plus d'efficacité.
-Xms2048m -Xmx2048m
- Vous pouvez également activer PermGen pour qu'il soit ramassé.
-XX: + UseConcMarkSweepGC -XX: + CMSPermGenSweepingEnabled -XX: + CMSClassUnloadingEnabled
Si la page change trop souvent pour rendre cette option logique, essayez de mettre temporairement en cache le contenu dynamique afin qu'il ne soit pas nécessaire de le régénérer encore et encore. Toutes les techniques que vous pouvez utiliser pour mettre en cache un travail déjà effectué au lieu de le refaire doivent être utilisées - c'est la clé pour obtenir les meilleures performances Tomcat.
S'il y a un problème lié à la base de données, alors peut suivre sql query perfomance tuning
rotation du fichier Catalina.out log,
without restarting Tomcat.
Dans les détails, il y a deux façons.
Le premier , qui est plus direct, permet de faire pivoter Catalina.out en ajoutant un simple tuyau à l'outil de rotation du journal de votre choix dans le script Shell de démarrage de Catalina. Cela ressemblera à quelque chose comme:
"$CATALINA_BASE"/logs/catalina.out WeaponOfChoice 2>&1 &
Remplacez simplement "WeaponOfChoice" par votre outil de rotation de journal préféré.
La seconde façon est moins directe, mais finalement meilleure. La meilleure façon de gérer la rotation de Catalina.out est de s’assurer qu’il n’a jamais besoin de la faire pivoter. Définissez simplement la propriété "swallowOutput" sur true pour tous les contextes dans "server.xml".
Ceci routera System.err et System.out vers l'implémentation de journalisation que vous avez configurée, ou JULI, si vous ne l'avez pas configurée.
- Plus d'infos sur: Tomcat Catalina Out
Nous avons rencontré un problème similaire, la cause était "catalina.out". Il s'agit du fichier journal de destination standard pour "System.out" et "System.err". Sa taille a continué à augmenter, ce qui a ralenti les choses et finalement, Tomcat s'est écrasé. Ce problème a été résolu en faisant tourner "catalina.out". Nous utilisions redhat, nous avons donc créé un script Shell pour faire pivoter "catalina.out".
Voici quelques liens: -
L'article de Mulesoft sur la catalina (contient également deux méthodes de rotation):
Introduction de Tomcat Catalina
Si "catalina.out" n'est pas le problème, essayez plutôt ceci: -
Article de Mulesoft sur l'optimisation de Tomcat: Optimisation des performances de Tomcat pour une vitesse optimale
Nous avons eu un problème qui ressemble au vôtre. Tomcat a tardé à répondre, mais le journal des accès ne contenait qu'une réponse en millisecondes. Le problème était le streaming des réponses. L'un de nos services a renvoyé des données en temps réel auxquelles l'utilisateur pouvait s'abonner. EPOLL devenaient gonflés. Les requêtes réseau ne pouvaient pas parvenir au Tomcat. Et quoi de plus intéressant, le processeur était principalement inactif (puisque personne ne pouvait demander au serveur de faire quoi que ce soit) et les threads accepteur/interrogateur étaient assis dans WAIT, pas RUNNING ou IN_NATIVE.
À l'époque, nous avons seulement limité le nombre de demandes et tout est devenu normal.