2010-09-23 9 views
5

आवेदन, जब लोड के अधीन होता है, कभी-कभी, 100% का उपयोग करता है।100% सीपीयू उपयोग के साथ WAITING राज्य में अपाचे टॉमकैट थ्रेड

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

राज्य भी नहीं बदलता है जब आवेदन संदर्भ undeployed है या डीबी पुनरारंभ:

ऐसा करके एक kill -quit <pid> के रूप में राज्य प्रतीक्षा में 1100+ धागे दिखाया।

कृपया एक संभावित कारण बताएं।

अनुप्रयोग सर्वर: अपाचे बिलाव 6.0.26

मैक्स धागे: 1500

धागे प्रतीक्षारत राज्य में: 1138

उत्तर

4

"इंतज़ार कर पर" नहीं एक समस्या है । धागा अधिसूचित होने की प्रतीक्षा कर रहा है - और इस मामले में यह JIoEndpoint.Worker

पृष्ठभूमि धागा कि भेजे टीसीपी/आईपी कनेक्शन और हाथ उन्हें एक उचित प्रोसेसर के बंद के लिए सुनता पर बंद है।

तो मैं इस वास्तविक अनुरोधों में आने के लिए इंतज़ार कर रहा है लगता है।

सबसे पहले, CPU उपयोग वास्तव में बढ़ जाती है कि आप कई धागे due to high amount of context switching है जब। क्या आपको वास्तव में 1500 की आवश्यकता है? क्या आप कम करके कोशिश कर सकते हैं?

दूसरा, क्या यह मेमोरी होगिंग या जीसी-आईएनजी अक्सर होता है?

" के लिए" यदि आप उन्हें देखते हैं तो एक समस्या होगी। क्या आपके पास स्टैक ट्रेस में कोई ब्लॉक्ड (ऑब्जेक्ट मॉनीटर पर) या लॉक() लॉक करने का इंतजार है?

+0

हम 7500 समवर्ती उपयोगकर्ताओं के साथ लोड-परीक्षण कर रहे हैं। क्या समरूपता अनुपात में धागे के लिए कोई ballpark है? –

+3

@ मोहित: लोड परीक्षण जाने का सही तरीका है। यह इस बात पर निर्भर करता है कि प्रति उपयोगकर्ता प्रत्येक अनुरोध कितना समय लेता है और वे आम तौर पर क्या प्रोसेसिंग करेंगे। http://people.apache.org/~mturk/docs/article/ftwai.html कहता है * टॉमकैट से अधिक लाभ उठाने के लिए आपको समवर्ती अनुरोधों की संख्या 200 प्रति CPU तक सीमित करनी चाहिए। * – JoseK

+0

7500 समवर्ती ** उपयोगकर्ता या अनुरोध ** - यह काफी है - तो क्या आप क्लस्टर हैं? – JoseK

0

एक सोलारिस प्रणाली आप कमांड

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

यह आपको CPU पर काम कर रही प्रत्येक प्रक्रिया की नीचे एक ब्रेक दे देंगे और प्रकाश वजन प्रोसेसर आईडी के आधार पर होगा उपयोग कर सकते हैं पर, के बजाय पीआईडी । जब आप अपने थ्रेड डंप को देखते हैं तो आप अपने एनआईडी (या कार्यान्वयन के आधार पर टीआईडी) तक हल्के वजन की प्रक्रिया से मेल खा सकते हैं जो आपके थ्रेड डंप की शीर्ष पंक्ति पर दिखाए जाते हैं। इन दो चीजों से मेल करके आप यह बताने में सक्षम होंगे कि आपके कौन से धागे सीपीयू हॉग हैं।

यहां आउटपुट का एक उदाहरण है।

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 

तो एक इसी धागा डंप के साथ, आप इन धागे

"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 

तो यह उच्च सीपीयू मामले के मामले में पा सकते हैं, समस्या कचरा संग्रहण में था।यह एलडब्ल्यूपीआईडी ​​क्षेत्र

के साथ निड से मेल करके देखा जाता है यदि यह आपकी मदद करेगा तो मैं एक स्क्रिप्ट बनाने का सुझाव दूंगा जो आपके प्रिस्टेट और सीपीयू उपयोग को एक साथ में ले जाएगा। यह आपको आपके आवेदन का सबसे सटीक प्रतिनिधित्व प्रदान करेगा।

आपके मूल दो धागे के अनुसार, @ जोसेक सही था। वे धागे बैठे हैं और उपयोगकर्ता से अनुरोध लेने का इंतजार कर रहे हैं। वहां कोई समस्या नहीं है।

+0

Thx, इसे आगे निदान करने के लिए इसे आजमाएं। –

संबंधित मुद्दे