Fils Apache Tomcat en état d'attente avec une utilisation de 100% du processeur

Question

L'application, lorsqu'elle est soumise à une charge, utilise parfois 100%.

fait un kill -quit <pid> montré 1100+ fils dans l'état d'attente que:

Full thread dump Java HotSpot(TM) 64-Bit Server VM (16.3-b01 mixed mode): 

"http-8080-1198" daemon prio=10 tid=0x00007f17b465c800 nid=0x2061 in Object.wait() [0x00007f1762b6e000] 
    java.lang.Thread.State: WAITING (on object monitor) 
     at java.lang.Object.wait(Native Method) 
     - waiting on <0x00007f17cb087890> (a org.apache.tomcat.util.net.JIoEndpoint$Worker) 
     at java.lang.Object.wait(Object.java:485) 
     at org.apache.tomcat.util.net.JIoEndpoint$Worker.await(JIoEndpoint.java:458) 
     - locked <0x00007f17cb087890> (a org.apache.tomcat.util.net.JIoEndpoint$Worker) 
     at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:484) 
     at java.lang.Thread.run(Thread.java:619) 

"http-8080-1197" daemon prio=10 tid=0x00007f17b465a800 nid=0x2060 in Object.wait() [0x00007f1762c6f000] 
    java.lang.Thread.State: WAITING (on object monitor) 
     at java.lang.Object.wait(Native Method) 
     - waiting on <0x00007f17cb14f460> (a org.apache.tomcat.util.net.JIoEndpoint$Worker) 
     at java.lang.Object.wait(Object.java:485) 
     at org.apache.tomcat.util.net.JIoEndpoint$Worker.await(JIoEndpoint.java:458) 
     - locked <0x00007f17cb14f460> (a org.apache.tomcat.util.net.JIoEndpoint$Worker) 
     at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:484) 
     at java.lang.Thread.run(Thread.java:619) 
............ 

L'état ne change pas même lorsque le contexte d'application est le DB OU non déployé est redémarré.

Veuillez suggérer une cause probable.

App serveur: Apache Tomcat 6.0.26

Max Threads: 1500

Threads dans l'état WAITING: 1138

Answer 1

"en attente sur" est pas un problème . Le fil est en attente d'être informé - et dans ce cas, il est verrouillé sur le JIoEndpoint.Worker

Le fil d'arrière-plan qui écoute les connexions TCP/IP entrants et les mains les hors d'un processeur approprié.

Je pense donc ceci est en attente pour les demandes réelles à venir.

Tout d'abord, l'utilisation du processeur augmente réellement lorsque vous avez beaucoup de discussions due to high amount of context switching. Avez-vous réellement besoin de 1500? Pouvez-vous essayer en réduisant?

Deuxièmement, est-ce que la mémorisation ou la GC-ing sont trop fréquentes? "Attente pour" serait un problème si vous les voyez. Avez-vous BLOQUÉ (sur le moniteur d'objet) ou en attente de verrouiller() dans la trace de la pile?

Answer 2

Sur un système Solaris, vous pouvez utiliser la commande

prstat -L -p <pid> 0 1 > filename.txt 

Cela vous donnera une ventilation de chaque processus faisant le travail sur la CPU et sera basé sur l'ID Light processeur de poids, au lieu du PID . Lorsque vous regardez votre vidage de fil, vous pouvez faire correspondre le processus de légèreté jusqu'à votre NID (ou TID en fonction des implémentations) qui sont affichés sur la ligne supérieure de votre vidage de thread. En faisant correspondre ces deux choses, vous serez en mesure de dire lequel de vos threads sont le porc CPU.

Voici un exemple de sortie.

PID USERNAME SIZE RSS STATE PRI NICE  TIME CPU PROCESS/LWPID 
    687 user  1024M 891M sleep 59 0 0:40:07 12.0% java/5 
    687 user  1024M 891M sleep 59 0 0:34:43 15.3% java/4 
    687 user  1024M 891M sleep 59 0 0:17:00 7.6% java/3 
    687 user  1024M 891M sleep 59 0 1:00:07 31.4% java/2 

Puis, avec une décharge de filetage correspondant, vous pouvez trouver ces fils

"GC task thread#0 (ParallelGC)" prio=3 tid=0x00065295 nid=0x2 runnable 
"GC task thread#1 (ParallelGC)" prio=3 tid=0x00nid=0x3 runnable 
"GC task thread#2 (ParallelGC)" prio=3 tid=0x0009a765 nid=0x4 runnable 
"GC task thread#3 (ParallelGC)" prio=3 tid=0x0003456b nid=0x5 runnable 

Ainsi, dans le cas de cette affaire élevée du processeur, le problème était dans la collecte des ordures.Ceci est vu en faisant correspondre le nid avec le champ LWPID

Si cela vous aide, je suggère de faire un script qui prendra la sortie de votre prstat et l'utilisation du processeur à la fois. Cela vous fournira la représentation la plus précise de votre application.

Selon vos deux discussions d'origine, @joseK était correcte. Ces threads sont assis et attendent de recevoir une requête d'un utilisateur. Il n'y a pas de problème là-bas.