Les paramètres de démarrage de Tomcat 5.5 permettent-ils d’adapter la machine virtuelle Java à une application Web extrêmement sollicitée et de grande taille?

Question

Nous avons récemment migré une application Web volumineuse et à forte demande de Tomcat 4 vers Tomcat 5.5 et nous avons constaté un comportement de ralentissement particulier qui semble être lié aux pauses de la JVM. Afin d'exécuter notre application et de prendre en charge l'augmentation de la charge avec le temps sous Tomcat 4, de nombreux paramètres JVM non standard ont été définis et optimisés comme indiqué ci-dessous, et j'espère qu'une personne expérimentée dans l'optimisation de la JVM Tomcat pourra commenter tout ce qui pourrait être préjudiciable. à une installation de Tomcat 5.5. Notez également que certaines d'entre elles pourraient être reportées des versions précédentes de Java (nous utilisions Tomcat 4 sur Java 1.6 avec ces paramètres avec succès depuis un certain temps, mais certaines ont peut-être été introduites pour aider la récupération de place sur Java 1.4, qui était à la base de Tomcat 4 est installé depuis longtemps et risque maintenant de faire plus de mal que de bien).

Quelques notes:

• L'empreinte mémoire de l'application est environ 1 Go, probablement un peu plus.
• La CPU n'est pas un problème - toutes les machines     servant l'application (charge équilibrée) sont     < 30% de la CPU
• Beaucoup de marge disponible sur la mémoire physique sur les machines.
• -XX: MaxPermSize = 512m était le seul paramètre ajouté dans le cadre de la mise à jour 5.5 et réagissait à un problème d'espace insensé (ce qu'il a résolu).
• Sous Java 1.6, SE Solaris

-server -Xms1280m -Xmx1280m -XX: MaxPermSize = 512m -XX: ParallelGCThreads = 20 -XX: + UseConcMarkSweepGC -XX: + UseParNewGC -XX: SurvivorRatio = 8 -XX: TargetSeVivorRatio = 75 -XP; XX: + AggressiveOpts -XX: + PrintGCDetails -XX: + PrintGCTimeStamps -XX: -TraceClassUnloading -Dsun.io.useCanonCaches = false -Dsun.net.client.defaultConnectTimeout = 60000 -Dsun.net.client.defaultReadTimeout = 60000 /. >

Answer 1

L'un des champions de Java, le blog de Kirk Pepperdine: http: //kirk.blog-city. com / how_to_cripple_gc_ergonomics.htm .
Citation 1 La documentation du GC vous dira ce que le réglage affecte, mais souvent sans dire quel sera l'effet. Le meilleur indice que vous ayez pris la mauvaise fourche sur la route est lorsque vous définissez explicitement une valeur, puis que vous donnez un indice à l'ergonomie de GC. Un autre indice est que si vous n'avez pas de bonne raison de modifier un paramètre. Et juste parce que certains soi-disant experts disent que ce réglage fonctionne le mieux, ce n’est que du bruit, pas du son, et certainement pas une raison. & <; P>

Citation 2 & "Comme je l'ai dit dans une entrée de blog précédente, ne touchez pas les boutons, sauf si vous avez une très bonne raison de le faire." Si vous devez toucher les boutons, faites-le légèrement en n'utilisant que ceux qui facilitent l'ergonomie et non ceux qui cachent des problèmes d'ergonomie paralysants pour atteindre vos objectifs en matière de temps de pause et de débit. & Quot;

Donc, je vous suggérerais de revenir en clair
-server -Xms1280m -Xmx1280m -XX: MaxPermSize = 512m -XX: + UseConcMarkSweepGC -XX: + PrintGCDetails -XX: + PrintGCTimeStamps -XX: -TraceClassUnloading -Dsun.io.use.CanonChats = false -Dsun.net.client.defaultReadTimeout = 60000

Trouvez si cela vous donne de meilleures performances. Si oui, respectez-le! BTW, est-ce que -XX: MaxPermSize = 378m avait des problèmes?
Java 1.6 a une bien meilleure ergonomie que 1.4. Vous voudrez peut-être accorder moins de 1,4!
BTW, avez-vous essayé Tomcat 6? Tomcat 6 fonctionne beaucoup mieux sur Java 6 que Tomcat 5.5.

P.S: J'utilise Tomcat depuis un moment maintenant et j'essaie généralement de laisser le règne libre sur le JDK de sun avec peu de réglages ici et là.

Answer 2

vient de trouver un webinaire de développeurs Tomcat sur l'optimisation de tomcat: http://springsource.com/node/555 . un suivi du webinaire: http://blog.springsource.com/2008/10/14/optimising-and-tuning-apache-tomcat-part-2/

BR,
~ A

Answer 3

En tant que personne qui est en train de jouer avec cela, je n’ai certainement pas de réponses définitives, surtout compte tenu de la spécificité de ce type de problème pour une application donnée. Une bonne référence, que vous avez probablement déjà vue, est la suivante:

http://java.sun.com/javase/technologies /hotspot/gc/gc_tuning_6.html

Cependant, la liste des paramètres jvm est assez longue, ce qui suggère que des paramètres inutiles sont probablement définis, en particulier étant donné que vous disposez de plusieurs options de débogage sur (PrintGCDetails, PrintGCTimeStamps, TraceClassUnloading) qui ne peuvent pas être efficaces sur une application de production. Les temps morts de 60 secondes pourraient également prendre beaucoup de ressources. " serveur " est le défaut mais ne fera aucun mal.

Comment l'application s'exécute-t-elle avec des paramètres de réglage minimaux (taille de jvm, MaxPermSize)?

Answer 4

Vous pouvez également envisager de modifier le nombre minimal / maximal de threads que Tomcat utilisera pour traiter les demandes dans conf/server.xml:

<Connector port="8080" maxThreads="150" minSpareThreads="25" maxSpareThreads="75" ...

Une règle de base que j'avais entendue dans un travail précédent était que maxThreads devait être égal à la quantité de connexions simultanées que vous espériez gérer. Je ne sais pas si cette affirmation est scientifique, mais je pense que cela a du sens, car vous ne voulez pas que les clients soient bloqués dans l’attente d’un fil à libérer pour traiter leur demande.

Answer 5

Il peut également être intéressant de faire l'essai d'une machine virtuelle alternative (telle que JRockit) pour voir si les différences entre le modèle de récupération de place et de mémoire sont bien adaptées à votre application.