2013-01-23 16 views
6

जैसा कि नीचे देखा गया है, वैसे ही काम करने वाली सभी चीज़ों के बीच में एक स्टॉप-द-वर्ल्ड जीसी ऑपरेशन ने +60 सेकंड लिया। यह पूरे समय के लिए दुनिया को रोकने के लिए निर्धारित किया जा सकता है, क्योंकि (टेराकोटा) ग्राहकों ने इसे छोड़ दिया, शिकायत (टेराकोटा सर्वर) उस समय के दौरान प्रतिक्रिया नहीं दी थी।जेवीएम मिनट लंबा जीसी

क्या यह युवा/मामूली जीसी है? यदि हां, तो क्या यह युवा पीढ़ी में भुखमरी के कारण हो सकता है (ईडन + बचे हुए?)।

केवल 109333 (केबी) मुक्त है?

मैं विभिन्न मेमोरी कंटेनरों को ग्राफिंग करना शुरू कर दूंगा, कोई अन्य सुझाव इस तरह की समस्याओं का निदान करने के लिए क्या किया जा सकता है?

date, startMem=24589884, endMem=24478495, reclaimed=111389, timeTaken=0.211244 (1172274.139: [GC 24589884K->24478495K(29343104K), 0.2112440 secs]) 
date, startMem=24614815, endMem=24505482, reclaimed=109333, timeTaken=61.301987 (1172276.518: [GC 24614815K->24505482K(29343104K), 61.3019860 secs]) 
date, startMem=24641802, endMem=24529546, reclaimed=112256, timeTaken=2.68437 (1172348.921: [GC 24641802K->24529546K(29343104K), 2.6843700 secs]) 

सूर्य JVM 1.6 है, निम्नलिखित config का उपयोग कर:

-Xms28672m -Xmx28672m -XX: + UseConcMarkSweepGC -XX: + PrintGCTimeStamps -XX: + PrintGC

साने जीसी को आगे डीबग करने के लिए विन्यास समायोजन:

'-XX:+PrintGCDateStamps' Print date stamps instead of relative timestamps 
'-XX:+PrintGCDetails' Will show what cpu went for (user, kern), gc algorithm used 
'-XX:+PrintHeapAtGC' will show all of the heaps memory containers and their usage 
'-Xloggc:/path/to/dedicated.log' log to specific file 
+0

आपका आवेदन क्या कर रहा है? जीसी जिटर तब होता है जब कई स्वीप में ढेर से बड़ी मात्रा में स्मृति को पुनः प्राप्त किया जा रहा है, संभव है कि प्रत्येक स्वीप अधिक ऑब्जेक्ट्स को संग्रह के योग्य बनने के कारण बनती है, जिससे आगे बढ़ता है। यहां तक ​​कि 2 सेकंड रन जो आप दिखाते हैं वह जीसी के लिए काफी समय है। मुझे लगता है कि आप बदल रहे होंगे कि आपका एप्लिकेशन ऑब्जेक्ट्स को कैसे प्रबंधित कर रहा है, जेवीएम कॉन्फ़िगरेशन की बजाय आपको जिस पथ को लेने की आवश्यकता है, वह होगा। जीसी जिटर को रखने की जरूरत रखने वाले किसी भी आवेदन को वस्तुओं को पुन: आवंटित करने के बजाय पुन: उपयोग करना चाहिए। – codeghost

+0

यह एक सत्र (कुकी) स्टोर है। संख्याएं, उदाहरण के लिए "पुनः दावा" इंगित करता है कि वास्तव में बहुत अधिक स्मृति को पुनः प्राप्त नहीं किया गया था। यदि ऐसा है तो यह जानना बहुत सुविधाजनक है क्यों। मैं आपसे पूरी तरह से सहमत हूं कि इसे हल करने की जरूरत है कि कैसे (सत्र) वस्तुओं को संभाला जाता है, उनमें क्या शामिल है। सत्रों को बेहतर तरीके से संभालने की प्रक्रिया है, लेकिन अभी तक मुझे यह पता लगाने का काम मिला है कि क्यों जीसी +60 सेकंड लेगा और अभी भी पिछले 0.2 जीसी की तुलना में अधिक स्मृति मुक्त नहीं होगा। – user135361

+2

इस ब्लॉग पर एक नज़र डालें http://kirk.blog-city.com/why_do_i_have_this_long_gc_pause.htm आपको कुछ पॉइंटर्स दे सकता है। – codeghost

उत्तर

1

-XX:+UseConcMarkSweepGC समवर्ती संग्रह के लिए सक्षम बनाता

Default Vs. CMS

कुल लिया रोकने के दुनिया चरणों (JVM अवरुद्ध) और समवर्ती चरणों (JVM उपयोगकर्ता कोड को क्रियान्वित करने) का योग है समय।

आपको आगे की जांच के लिए विस्तृत जीसी लॉगिंग सक्षम करना चाहिए, क्योंकि आपके पास कोई जानकारी नहीं है कि उसमें से कितने +60 सेकंड JVM को अवरुद्ध कर रहे हैं।

+0

मैंने पहले से ही रेखांकित किया है कि अधिक वर्बोज़ आउटपुट लॉग हो जाएगा। प्रश्न यह नहीं है कि सीएमएस कैसे काम करता है, बल्कि किस परिस्थिति में एक लंबे समय तक चलने वाली दुनिया होगी। JVM को पूरे समय अवरुद्ध कर दिया गया था, इसलिए यह एक "प्रमुख जीसी" है और यह डिफ्रैग्मेंटेशन की वजह से है। यदि हां, तो सवाल यह है कि मुझे कैसे पता चलेगा कि अधिक ढेर जोड़ने से मदद मिलेगी, या किस मामले में सीएम को पहले मदद में लात मारने के लिए शेड्यूल करना होगा। मैं आपकी कोशिश की सराहना करता हूं, लेकिन मुझे आपको ऊपर उठाने से पहले कारकों को अलग करने पर एक स्टैब लेना होगा। – user135361

+2

आप कैसे जानते हैं कि विस्तृत लॉग के बिना JVM को पूरे समय अवरुद्ध कर दिया गया था? आपको उस प्रश्न में जोड़ना चाहिए जो आपके पास है। – fglez

+0

अच्छा बिंदु, अद्यतन। – user135361

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