Apache Tomcat-Threads im Status WAITING mit 100% CPU-Auslastung

Question

Die Anwendung verwendet manchmal 100%, wenn sie belastet wird.

Doing a kill -quit <pid> zeigte 1100+ Fäden in Wartezustand als:

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) 
............ 

Der Zustand nicht ändern, selbst wenn die Anwendung-Kontext nicht entfalteten ist oder die DB neu gestartet wird.

Bitte schlagen Sie eine mögliche Ursache vor.

App Server: Apache Tomcat 6.0.26

Max Themen: 1500

Themen im Wartezustand: 1138

Answer 1

"Warte auf" ist kein Problem . Der Thread wartet informiert zu werden - und in diesem Fall ist es auf dem Gewinde JIoEndpoint.Worker

Der Hintergrund gesperrt, die für eingehende TCP/IP-Verbindungen und Hände sie weg auf einen geeigneten Prozessor hört.

Also ich denke, das für den tatsächlichen Anfragen wartet zu kommen.

Zum einen CPU-Auslastung tatsächlich erhöht, wenn Sie due to high amount of context switching viele Threads haben. Brauchst du eigentlich 1500? Können Sie es versuchen, indem Sie reduzieren?

Zweitens, ist es Speichermangel oder GC-ing zu oft?

"Warten auf für" wäre ein Problem, wenn Sie diese sehen. Verfügen Sie über BLOCKED (auf Objektmonitor) oder warten auf Sperren() in der Stapelüberwachung?

Answer 2

auf einem Solaris-System, das Sie den Befehl

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

können diese Sie jedes Prozesses eine Pause geben hinunter Arbeit an der CPU zu tun und wird auf dem Leichtgewichtler Prozessor-ID basiert, anstelle der PID . Wenn Sie sich Ihren Thread-Dump ansehen, können Sie den Light-Weight-Prozess an Ihre NID (oder TID, abhängig von den Implementierungen) anpassen, die in der oberen Zeile Ihres Thread-Dumps angezeigt wird. Indem Sie diese beiden Dinge zusammenbringen, können Sie feststellen, welche Ihrer Threads die CPU-Schweinerei sind.

Hier ist ein Beispiel für den Ausgang.

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 

dann mit einem entsprechenden Thread-Dump, können Sie diese Themen

"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 

So im Fall dieses hohen CPU-Falles finden, war das Problem in der Garbage Collection.Dies wird durch die Übereinstimmung der NID mit dem LWPID-Feld

gesehen. Wenn dies Ihnen helfen wird, würde ich vorschlagen, ein Skript, das die Ausgabe Ihrer prstat und die CPU-Auslastung auf einmal nehmen wird. Dadurch erhalten Sie die genaueste Darstellung Ihrer Anwendung.

Wie bei Ihren ursprünglichen zwei Threads war @joseK korrekt. Diese Threads warten und warten auf eine Anfrage von einem Benutzer. Dort gibt es kein Problem.