2013-03-11 5 views
8

नहीं जोड़ता है मेरे पास निम्न jHiccup परिणाम है।jHiccup विश्लेषण

jHiccup analysis graph

जाहिर है ग्राफ में कुछ सेकेंड की भारी चोटियों कर रहे हैं। मेरा ऐप आउटपुट प्रत्येक 100 एमएस या तो लॉग करता है। जब मैं अपने लॉग पढ़ता हूं तो मुझे ऐसे बड़े विराम कभी नहीं दिखाई देते हैं। इसके अलावा, मैं कुल समय JVM निदान से जीसी में खर्च की जांच कर सकते हैं और यह निम्नलिखित कहते हैं:

Time:  
2013-03-12 01:09:04 
Used:  
 1,465,483 kbytes 
Committed:  
 2,080,128 kbytes 
Max:  
 2,080,128 kbytes 
GC time:  
     2 minutes on ParNew (4,329 collections) 

8.212 seconds on ConcurrentMarkSweep (72 collections) 

कुल बड़े जीसी समय लगभग 8 सेकंड 72 अलग संग्रहों में फैला हुआ है। विराम को सीमित करने के लिए वे सभी मेरे JVM संकेत के अनुसार 200ms से नीचे हैं।

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

मेरा प्रश्न यह है कि इस व्यवहार को डीबग या ट्यून करने का सबसे अच्छा तरीका क्या होगा?

इसके अतिरिक्त, मैं समझना चाहता हूं कि jHiccup माप कैसे करता है। जाहिर है यह जीसी विराम समय नहीं है।

उत्तर

24

यह देखने के लिए खुशी है कि आप jHiccup का उपयोग कर रहे हैं, और ऐसा लगता है कि यह वास्तविकता-आधारित हिचकी दिखाता है।

jHiccup "हिचकी" को देखता है जो JVM पर चल रहे एप्लिकेशन थ्रेड द्वारा भी देखा जाएगा। यह कारण नहीं है - बस तथ्य की रिपोर्ट करता है। कारण कुछ भी हो सकता है जो पूरी तरह से तैयार कोड चलाने के लिए प्रक्रिया नहीं करेगा: जीसी विराम एक आम कारण है, लेकिन कुंजीपटल पर एक अस्थायी^ज़ेड, या वर्चुअलाइज्ड होस्टों में उन "लाइव माइग्रेशन" चीजों में से एक होगा ओएस या हाइपरवाइजर स्तर (अगर कोई मौजूद है), पावर मैनेजमेंट पागलपन, स्वैपिंग और कई अन्य लोगों में शेड्यूलिंग दबाव सहित कई संभावित कारण हैं। मैंने लिनक्स फ़ाइल सिस्टम दबाव और पारदर्शी विशाल पृष्ठ "पृष्ठभूमि" डीफ्रैग्मेंटेशन को मल्टी-सेकंड हिचक्यू के कारण भी देखा है ...

विराम के कारण को अलग करने का एक अच्छा पहला कदम "-c" विकल्प का उपयोग करना है jHiccup में: यह एक अलग नियंत्रण प्रक्रिया शुरू करता है (अन्यथा निष्क्रिय वर्कलोड के साथ)। यदि आपके आवेदन और नियंत्रण प्रक्रिया दोनों आकार और समय में लगभग सहसंबंधित हिचकी दिखाते हैं, तो आप जान लेंगे कि आप सिस्टम-स्तर (प्रक्रिया-स्थानीय के विपरीत) कारण ढूंढ रहे हैं। यदि वे सहसंबंध नहीं करते हैं, तो आपको अपने जेवीएम के अंदरूनी संदेह की जानकारी होगी - जो संभवतः आपके जेवीएम को कुछ बड़े के लिए रोका गया है; या तो जीसी या कुछ और, जैसे लॉक डेबियसिंग या क्लास-लोडिंग-डेरिवने-डीओप्टाइमाइजेशन जो कुछ जेवीएम पर वास्तव में लंबे समय तक [और अक्सर लॉग इन नहीं किया जाता] समय ले सकता है यदि समय-से-सुरक्षित बिंदु कुछ कारणों से लंबा है (और चालू अधिकांश जेवीएम, लंबे समय से सुरक्षित बिंदु के लिए कई संभावित कारण हैं)।

jHiccup का माप इतनी गंदगी-सरल है कि गलत होना मुश्किल है। पूरी बात जावा कोड की 650 लाइनों से कम है, इसलिए आप अपने लिए तर्क देख सकते हैं। jHiccup's HiccupRecorder थ्रेड बार-बार 1 एमसीईसी के लिए सो जाता है, और जब यह जागता है तो यह समय में (नींद से पहले) में कोई अंतर दर्ज करता है जो 1msec एक हिचकी के रूप में बड़ा होता है। सरल धारणा यह है कि यदि एक तैयार-टू-रन थ्रेड (हिकोक्रिकॉर्डर) 5 सेकेंड तक नहीं चल पाता है, तो उसी प्रक्रिया में अन्य धागे में भी एक समान आकार का हिचकी दिखाई देती है।

जैसा कि आप ऊपर नोट करते हैं, jhiccups अवलोकन आपके स्वतंत्र नेटवर्क लॉग में पुष्टि की जाती है, जहां आपने 5 सेकंड प्रतिक्रिया समय देखा था, ध्यान दें कि नेटवर्क लॉग द्वारा सभी हिचकी नहीं देखी गईं, क्योंकि वास्तव में केवल अनुरोध किए गए अनुरोध नेटवर्क लॉगर द्वारा हिचकी देखी गई होगी।इसके विपरीत, ~ 1msec से बड़ा कोई हिचकी jHiccup से छिपी नहीं जा सकती है, क्योंकि यह किसी अन्य गतिविधि के साथ प्रति सेकेंड 1,000 बार जागने का प्रयास करेगी।

यह जीसी नहीं हो सकता है, लेकिन इससे पहले कि आप जीसी से बाहर निकलें, मैं सुझाव दूंगा कि आप जीसी लॉगिंग को थोड़ा और देखेंगे। आरंभ करने के लिए, 200 एमसीईसी को रोकने के लिए एक JVM संकेत सभी ज्ञात JVMs पर बेकार है। एक विराम संकेत "कृपया" कहने के बराबर है। इसके अतिरिक्त, अपने जीसी लॉग पर विश्वास न करें जब तक कि आप विकल्पों में -XX: + प्रिंटजीसी एप्प्लिकेशनस्टॉपटाइम शामिल नहीं करते हैं (और तब भी उन्हें संदेह करें)। ऐसे विराम और विराम के कुछ भाग हैं जो बहुत लंबे समय तक हो सकते हैं और जब तक आप इस ध्वज को शामिल नहीं करते हैं तब तक रिपोर्ट नहीं किया जाता है। जैसे मैंने कभी-कभी लंबे समय तक चलने वाले गलती वाले लूप के कारण 15 सेकंड तक एक सुरक्षित बिंदु तक पहुंचने के कारणों को देखा है, जहां जीसी ने केवल विराम के केवल .08 सेकेंड हिस्से की सूचना दी जहां वास्तव में कुछ काम किया। ऐसे कई विराम भी हैं जिनके कारणों को "जीसी" का हिस्सा नहीं माना जाता है और इस प्रकार जीसी लॉगिंग झंडे द्वारा रिपोर्ट नहीं किया जा सकता है।

- गिल। [jHiccup के लेखक]

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