जेबॉस धागे यादृच्छिक मॉनिटर पर इंतजार कर रहे हैं

मैं जेबॉस में तैनात एक वेब ऐप पर कुछ लोड परीक्षण कर रहा हूं। यह ठीक शुरू होता है, लेकिन जैसा कि ऊपर परीक्षण रैंप और अधिक नकली उपयोगकर्ताओं JBoss मार शुरू, प्रदर्शन गंभीर रूप से खराब हो:जेबॉस धागे यादृच्छिक मॉनिटर पर इंतजार कर रहे हैं

Resposne time chart http://i46.tinypic.com/2mob2f9.jpg

इसे करने के लिए VisualVM कनेक्ट, मैं देख सकता धागे सब ठीक थे, तो अचानक खर्च करना शुरू कर दिया

Thread state graph http://i46.tinypic.com/105v6lk.jpg

jstack चल रहा है, मैं धागे एक ही स्थान इंतजार कर रहे हैं देखें:: अपना अधिकांश समय एक मॉनिटर के लिए इंतज़ार कर (हरा चल रहा है, लाल मॉनिटर है, पीले इंतजार है)

"http-0.0.0.0-8080-172" daemon prio=6 tid=0x000000005da90000 nid=0xd2c waiting for monitor entry [0x000000006cb4e000] 
    java.lang.Thread.State: BLOCKED (on object monitor) 
    at org.apache.log4j.Category.callAppenders(Category.java:185) 
    - waiting to lock (a org.apache.log4j.spi.RootCategory) 
    at org.apache.log4j.Category.forcedLog(Category.java:372) 
    at org.apache.log4j.Category.debug(Category.java:241) 
    [my code]

~ 200 HTTP प्रोसेसर धागे अधिकांश मॉनीटर के लिए प्रतीक्षा कर रहे हैं। WAR के लिए log4j.xml को देखते हुए, इसमें CONSOLE के लिए एक एकल एपेंडर सेटअप है। मैं एपेंडर को हटाता हूं और फिर से अपना परीक्षण करने की कोशिश करता हूं। समान व्यवहार, jstack को छोड़कर सभी धागे एक अलग जगह में इंतज़ार कर पता चलता है:

"http-0.0.0.0-8080-251" daemon prio=6 tid=0x0000000059811800 nid=0x1108 waiting for monitor entry [0x0000000073ebe000] 
    java.lang.Thread.State: BLOCKED (on object monitor) 
    at java.util.Hashtable.get(Hashtable.java:333) 
    - waiting to lock (a org.jboss.util.property.PropertyMap) 
    at java.util.Properties.getProperty(Properties.java:932) 
    at org.jboss.util.property.PropertyMap.getProperty(PropertyMap.java:626) 
    at java.lang.System.getProperty(System.java:653) 
    at org.jaxen.saxpath.helpers.XPathReaderFactory.createReader(XPathReaderFactory.java:109) 
    at org.jaxen.BaseXPath.(BaseXPath.java:124) 
    at org.jaxen.BaseXPath.(BaseXPath.java:153) 
    at nu.xom.JaxenConnector.(JaxenConnector.java:49) 
    at nu.xom.Node.query(Node.java:424) 
    [my code]

कुछ भी नहीं बदल रहा है, मैं पुनः आरंभ JBoss, परीक्षण चलाने, तो jstack चलाने एक बार यह धीमी गति से हो जाता है। सभी धागे अभी तक एक अलग जगह में इंतजार कर रहे हैं:

"http-0.0.0.0-8080-171" daemon prio=6 tid=0x000000005d0d1000 nid=0x15d4 waiting for monitor entry [0x000000006cb4e000] 
    java.lang.Thread.State: BLOCKED (on object monitor) 
    at sun.nio.cs.FastCharsetProvider.charsetForName(FastCharsetProvider.java:118) 
    - waiting to lock (a sun.nio.cs.StandardCharsets) 
    at java.nio.charset.Charset.lookup2(Charset.java:449) 
    at java.nio.charset.Charset.lookup(Charset.java:437) 
    at java.nio.charset.Charset.isSupported(Charset.java:479) 
    at sun.nio.cs.StreamDecoder.forInputStreamReader(StreamDecoder.java:49) 
    at java.io.InputStreamReader.(InputStreamReader.java:57) 
    at java.io.FileReader.(FileReader.java:41) 
    [my code]

बिल्ली में क्या चल रहा है? मैंने अतीत में जेस्टैक का उपयोग किया है और जब चीजें ठीक चल रही हैं और अपेक्षित परिणाम मिलते हैं तो मैंने इसे चलाने की कोशिश की। मुझे लगता है कि जेस्टैक ठीक है। कोई विचार क्या अजीब व्यवहार का कारण बन सकता है? यहां से कहां जाना है इस पर कोई विचार?

स्रोत

2010-06-29 NateS

अधिक संदर्भ/जानकारी के बिना, यह कहना मुश्किल है कि क्या हो रहा है। आम तौर पर, ऐसा लगता है कि विभिन्न संसाधनों और/या संभावित डेडलॉक स्थिति के लिए बहुत सारी विवाद है। आपके पहले चरण के रूप में, ऐसा लगता है जैसे आपने log4j के लिए कुछ विवाद हटा दिया है। कैशिंग क्वेरी परिणामों के कुछ संयोजन या डेटा संरचनाओं तक पहुंच को सिंक्रनाइज़ करने के द्वारा अन्य दो संसाधनों के लिए एक ही चीज़ करना संभव है जो डेडलॉक का कारण बन सकता है? – btreat

मुझे और जानकारी प्रदान करने में खुशी है, मुझे यकीन नहीं है कि क्या प्रदान करना है। अजीब बात यह है कि, हालांकि बहुत सारी विवाद है, धागे deadlocked नहीं हैं। वे 2 से 10+ सेकेंड के लिए मॉनीटर पर प्रतीक्षा करते हैं, फिर निष्पादन जारी रहता है, फिर मॉनीटर पर फिर से इंतजार करने के तुरंत बाद। कॉल बहुत बुनियादी हैं (उदाहरण के लिए System.getProperties) और इससे बचा नहीं जा सकता है। जेबॉस और अन्य तृतीय पक्ष कोड इन कॉल करते हैं। चूंकि मुझे पूरा यकीन है कि System.getProperties और हैशटेबल ठोस हैं, मेरा अगला सबसे अच्छा अनुमान यह है कि विवाद होने पर जेस्टैक भ्रामक है। यदि हां, तो मैं और कैसे निर्धारित कर सकता हूं कि विवाद कहाँ होता है? – NateS

मैंने एक्लिप्स के माध्यम से टॉमकैट में एप्लिकेशन स्थापित किया और समस्या को नहीं देखा। आखिरकार मैंने पाया कि हम 32-बिट विंडोज सर्विस रैपर का उपयोग कर जेबॉस शुरू कर रहे थे, भले ही हम 64-बिट जेडीके का उपयोग कर रहे थे। मशीन 64-बिट थी। मुझे यकीन नहीं है कि यह कैसे काम करेगा? किसी भी दर पर, 32-बिट जेडीके में बदलने से पागल समस्या दूर हो गई और मैं अपने जीवन के साथ आगे बढ़ने में सक्षम था।

स्रोत

2010-08-26 22:31:22 NateS

इस प्रकार के व्यवहार की अपेक्षा की जा सकती है। जैसे ही आप लोड टेस्ट को स्केल करते हैं, आपको हमेशा बाधाएं मिलती रहती हैं, और एक जटिल प्रणाली में, उन बाधाओं को चारों ओर स्थानांतरित करने जा रहे हैं।

आपका काम उन बाधाओं को पहचानना और उन्हें एक बार ठीक करने का प्रयास करना है। हर बार जब आप करते हैं, तो आपको हमेशा एक और मिल जाएगा, लेकिन उम्मीद है कि सिस्टम हर बार बेहतर होगा। यह आसान नहीं है, लेकिन फिर लोड के लिए स्केलिंग आसान नहीं है।

अपना पहला उदाहरण लें। आपके पास log4j की Logger.debug() विधि पर बहुत सी कॉल हैं। लॉग 4j लोड के तहत लॉग इन करते समय अच्छा प्रदर्शन नहीं करता है, इसलिए आपको कुछ सावधानी बरतनी होगी। भले ही आपकी log4j कॉन्फ़िगरेशन "DEBUG संदेशों को लॉग न करें" कहता है, log4j को अभी भी इसे महसूस करने से पहले कुछ काम करना है। {Logger.debug() में प्रत्येक Logger.debug() कॉल को लपेटने के लिए अनुशंसित दृष्टिकोण है। } 'ब्लॉक। यह उस विशेष बाधा को बदलना चाहिए।
आपके दूसरे उदाहरण में, आप XOM की Node.query() विधि को कॉल कर रहे हैं। इस विधि को प्रत्येक कॉल पर XPath अभिव्यक्ति को पुन: संकलित करना है, और यह एक बाधा प्रतीत होता है। एक एपीआई खोजें जहां आप XPath अभिव्यक्ति को पूर्व-संकलित कर सकते हैं और इसका पुनः उपयोग कर सकते हैं।
तीसरे उदाहरण में, आप File पढ़ रहे हैं। यह एक उच्च लोड सिस्टम में एक अच्छा विचार नहीं है, जब आप बड़ी संख्या में छोटे परिचालन कर रहे हैं तो फ़ाइल-io धीमा है। यदि आप कर सकते हैं तो एक अलग तरीके से काम करने के लिए इसे पुनः कार्यान्वित करने पर विचार करें।

ये सभी असंबद्ध हैं, लेकिन लोड के लिए स्केलिंग करते समय आप सभी वर्तमान प्रदर्शन बाधाओं को देखेंगे। आप उन सभी से कभी भी छुटकारा नहीं पाएंगे, लेकिन उम्मीद है कि आप इसे उस बिंदु पर प्राप्त कर सकते हैं जहां यह काफी अच्छा है।

स्रोत

2010-06-29 07:03:40 skaffman

मुझे बाधाएं नहीं दिख रही हैं। Log4j कॉल (यहां तक कि फ़ाइल को क्रमशः लिखना), System.getProperty को कॉल करना, और Charset.is समर्थित कॉलिंग तेज़ ऑपरेशन हैं, आमतौर पर कॉल नहीं होने की आवश्यकता होती है। मैं केवल 250 धागे चला रहा हूँ। ये ताले आम तौर पर बहुत तेजी से जाने देते हैं। System.getProperty पर 100+ धागे इंतजार कर रहे हैं का अर्थ है हैशटेबल को लॉक करना थ्रेड लंबा समय ले रहा है। लॉकिंग थ्रेड सिर्फ Hashtable.get को बुला रहा है। इसके लिए लंबे समय तक लेने के कुछ कारण हैं। शायद jstack भ्रामक है? असंभव लगता है, क्योंकि जब वेब ऐप सुचारू रूप से चल रहा है तो यह अवरुद्ध थ्रेड दिखाता नहीं है। – NateS

@NateS: वे तेजी से संचालन कर सकते हैं, लेकिन वे सिंगल-थ्रेडेड हैं, और इससे उन्हें बाधाएं मिलती हैं। इससे कोई फर्क नहीं पड़ता कि वे कितने तेज़ हैं, वे समवर्ती नहीं हैं। आपके स्वयं के ढेर डंप यह साबित करते हैं। – skaffman

मुझे विश्वास नहीं है कि एक साधारण परीक्षण कार्यक्रम जिसमें 250 थ्रेड थे, सभी सिस्टम कॉलिंग .getProperties एक ही विवाद समस्या दिखाएंगे जो मैं अपने ऐप के साथ देख रहा हूं। – NateS

जेबॉस धागे यादृच्छिक मॉनिटर पर इंतजार कर रहे हैं

उत्तर

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