2010-05-25 13 views
12

एकत्रित मैं समवर्ती मार्क-स्वीप कलेक्टर के साथ एक आवेदन पत्र के जीसी लॉग फ़ाइल पर निम्न लक्षणों में दिखाई दे रही है:JVM सीएमएस कचरा मुद्दे

4031.248: [CMS-concurrent-preclean-start] 
4031.250: [CMS-concurrent-preclean: 0.002/0.002 secs] [Times: user=0.00 sys=0.00, real=0.00 secs] 
4031.250: [CMS-concurrent-abortable-preclean-start] 
CMS: abort preclean due to time 4036.346: [CMS-concurrent-abortable-preclean: 0.159/5.096 secs] [Times: user=0.00 sys=0.01, real=5.09 secs] 
4036.346: [GC[YG occupancy: 55964 K (118016 K)]4036.347: [Rescan (parallel) , 0.0641200 secs]4036.411: [weak refs processing, 0.0001300 secs]4036.411: [class unloading, 0.0041590 secs]4036.415: [scrub symbol & string tables, 0.0053220 secs] [1 CMS-remark: 16015K(393216K)] 71979K(511232K), 0.0746640 secs] [Times: user=0.08 sys=0.00, real=0.08 secs] 

preclean प्रक्रिया लगातार निरस्त किया जा रहा रखता है। मैंने 5 के डिफ़ॉल्ट से CMSMaxAbortablePrecleanTime को 15 सेकंड में समायोजित करने का प्रयास किया है, लेकिन इससे मदद नहीं मिली है। वर्तमान JVM विकल्प इस प्रकार हैं ...

Djava.awt.headless=true 
-Xms512m 
-Xmx512m 
-Xmn128m 
-XX:MaxPermSize=128m 
-XX:+HeapDumpOnOutOfMemoryError 
-XX:+UseParNewGC 
-XX:+UseConcMarkSweepGC 
-XX:BiasedLockingStartupDelay=0 
-XX:+DoEscapeAnalysis 
-XX:+UseBiasedLocking 
-XX:+EliminateLocks 
-XX:+CMSParallelRemarkEnabled 
-verbose:gc 
-XX:+PrintGCTimeStamps 
-XX:+PrintGCDetails 
-XX:+PrintHeapAtGC 
-Xloggc:gc.log 
-XX:+CMSClassUnloadingEnabled 
-XX:+CMSPermGenPrecleaningEnabled 
-XX:CMSInitiatingOccupancyFraction=50 
-XX:ReservedCodeCacheSize=64m 
-Dnetworkaddress.cache.ttl=30 
-Xss128k 

यह समवर्ती-abortable-preclean कभी नहीं दिखाई देता है चलाने के लिए एक मौका हो जाता है। मैंने https://blogs.oracle.com/jonthecollector/entry/did_you_know के माध्यम से पढ़ा जिसमें सीएमएसएसकेवेन्जबेयररमार्क को सक्षम करने का सुझाव था, लेकिन रोके जाने के दुष्प्रभाव आदर्श नहीं लगते थे। क्या कोई भी सुझाव दे सकता है?

[1 CMS-remark: 16015K(393216K)] 71979K(511232K), 0.0746640 secs] 

क्या स्मृति क्षेत्रों उन संख्याओं की बात कर रहे पर स्पष्ट नहीं:

इसके अलावा, मैं अगर कोई, सीएमएस जीसी लॉग grokking के लिए एक अच्छा संदर्भ था विशेष इस पंक्ति में सोच रहा था। संपादित के लिए एक लिंक मिले इस http://www.sun.com/bigadmin/content/submitted/cms_gc_logs.jsp

+0

सीएमएस टैग सामग्री-प्रबंधन प्रणालियों के संदर्भ में उपयोग किया जाता है, समवर्ती चिह्न और स्वीप जीसी नहीं। मैं इसे हटा दूंगा। –

+0

जो लोग इसके बारे में खेद करते हैं, धन्यवाद – jlintz

+0

50% पर सीएमएस शुरू करना मेरे लिए बहुत कम लगता है: -XX: CMSInitiatingOccupancyFraction = 50 शायद इसे बढ़ाना (या 'एंटीस्पाम' सुझावों के रूप में डिफ़ॉल्ट का उपयोग करना) अलग-अलग व्यवहार करेगा। इसके अलावा, मेरे लॉग में आमतौर पर ParNew उन्हें CMS के पहले, दौरान और उसके बाद चल रहा है। क्या ParNew चल रहा है? –

उत्तर

3

[टाइम्स: उपयोगकर्ता = 0.00 sys = 0.01, अचल = 5.09 सेकेंड]

मैं जांच की कोशिश करेगा क्यों CMS-concurrent-abortable-preclean-start न तो उपयोगकर्ता नहीं मिलता है और न ही sys CPU समय 5 सेकंड में।

मेरे सुझाव

-Djava.awt.headless=true 
-Xms512m 
-Xmx512m 
-Xmn128m 
-Xss128k 
-XX:MaxPermSize=128m 
-XX:+UseConcMarkSweepGC 
-XX:+HeapDumpOnOutOfMemoryError 
-Xloggc:gc.log 
-XX:+PrintGCTimeStamps 
-XX:+PrintGCDetails 
-XX:+PrintHeapAtGC 

की तरह एक 'साफ़' JVM सीएमएस स्टार्टअप झंडे से शुरू कर रहा है तो देखें कि समस्या reproduces और एक समय में एक पैरामीटर फेरबदल रहते हैं।

3

जैसा कि किसी ने पहले से ही उल्लेख किया है, पहला कदम सीएमएसइनिटीटिंगऑक्चेंसी फ्रैक्शन को बढ़ाने के लिए होगा।

दूसरे चरण के रूप में, मैं ध्वज -XX:-PrintTenuringDistribution का उपयोग करता हूं और सुनिश्चित करता हूं कि युवा पीढ़ी से पुराने समय तक कोई समयपूर्व पदोन्नति नहीं है। यह पुराने-से-युवा संदर्भों का कारण बनता है जो लंबे समय तक निरंतर पूर्ववर्ती चरण का कारण बन सकता है। यदि ऐसा समयपूर्व पदोन्नति है, तो ईडन और जीवित रिक्त स्थान के बीच अनुपात समायोजित करने का प्रयास करें।

2

एक अच्छा स्पष्टीकरण here इस घटना के बारे में नहीं है:

उद्धरण:

तो जब सिस्टम लोड प्रकाश (कोई नाबालिग जीसी नहीं होगा जिसका मतलब है) है, precleaning हमेशा होगा टाइम आउट और पूर्ण जीसी हमेशा असफल हो जाएगा। सीपीयू बर्बाद है।

यह असफल नहीं होगा। यह कम समानांतर होगा (यानी कम कुशल, और कम काम के लिए लंबे समय तक रोक देगा)।

तो सब में: इस सामान्य ऑपरेशन हो रहा है - धागा बस एक छोटी सी जी सी 5 सेकंड के लिए होने के लिए इंतजार कर रहा है, लेकिन कोई बड़ा मुद्दा जब ऐसा नहीं होता है है: JVM एक अलग चुनता है (कम कुशल) जीसी के साथ जारी रखने की रणनीति।