जावा में स्मृति विखंडन का विश्लेषण कैसे करें?

हम अपने सर्वर में कई मिनट लगते हैं। शायद वे "दुनिया को रोकें" कचरा संग्रह से ट्रिगर कर रहे हैं। लेकिन हम समवर्ती चिह्न और स्वीप जीसी (-XX: + UseConcMarkSweepG) का उपयोग करते हैं, इसलिए, मुझे लगता है कि, इन विरामों को पुरानी पीढ़ी के स्मृति विखंडन द्वारा ट्रिगर किया जाता है।जावा में स्मृति विखंडन का विश्लेषण कैसे करें?

पुरानी पीढ़ी के स्मृति विखंडन का विश्लेषण कैसे किया जा सकता है? क्या इसके लिए कोई उपकरण है?

झगड़े हर घंटे होते हैं। ज्यादातर समय वे लगभग 20 सेकंड होते हैं, लेकिन कभी-कभी - कई मिनट।

स्रोत

2009-08-10 Vitaly

क्या आप सुनिश्चित हैं कि यह जीसी है? विशेष रूप से, क्या वीएम प्रक्रिया विराम के दौरान उच्च CPU उपयोग दिखाती है? यदि नहीं, तो मुझे लगता है कि आपके पास दौड़ की स्थिति कहीं है। – Esko

यह दौड़ की स्थिति नहीं है, मुझे यकीन है। प्रोफाइलर में चेक किया गया, और हम लगभग ताले का उपयोग नहीं करते हैं, और व्यवहार अलग-अलग सर्वरों पर समान होता है - बस अलग-अलग अंतराल के समय। और उच्च CPU उपयोग नहीं - ऐप में सभी थ्रेड बंद कर दिए गए हैं। – Vitaly

[संपादित] जीसी लॉग चालू करने के बाद मुझे "पदोन्नति विफल" समस्या मिली। अच्छा विवरण यहां है: http://www.sun.com/bigadmin/content/submitted/cms_gc_logs.html। मदद के लिए हरबोड धन्यवाद। – Vitaly

जीसी लॉगिंग चालू करने के लिए "जावा-एक्स ..." विकल्पों के लिए अपने जावा दस्तावेज़ देखें। यह आपको बताएगा कि क्या आप पुरानी या नई पीढ़ी एकत्र कर रहे हैं, और संग्रह कितने समय तक ले रहे हैं।

"कई मिनट" का एक विराम असाधारण लगता है। क्या आप वाकई एक ढेर आकार के साथ नहीं चल रहे हैं जो बहुत छोटा है, या पर्याप्त भौतिक स्मृति वाले मशीन पर?

अपने ढेर भी भरा के करीब हैं, तो जीसी फिर से और फिर से अपने सर्वर जीसी में अपनी सीपीयू समय के सबसे अधिक खर्च करने में जिसके परिणामस्वरूप शुरू हो जाएगा। यह जीसी लॉग में दिखाई देगा।
आप पर्याप्त नहीं भौतिक स्मृति के साथ एक मशीन पर एक बड़ा ढेर का उपयोग करते हैं, एक पूर्ण जीसी अपने मशीन पैदा करने के लिए "पिटाई" के लिए उत्तरदायी है, अपने समय पागलों की तरह के सबसे खर्च करने के लिए आभासी स्मृति पृष्ठों चलती और डिस्क से। आप सिस्टम निगरानी उपकरण का उपयोग कर इसे देख सकते हैं; जैसे पर एक सामान्य यूनिक्स/लिनक्स सिस्टम पर "vmstat 5" से कंसोल आउटपुट देखकर।

अनुसरण करे

ओपी के धारणा के विपरीत, जीसी लॉगिंग चालू करना संभावना नहीं प्रदर्शन करने के लिए एक उल्लेखनीय अंतर बनाने के लिए है।

ओरेकल साइट पर Understanding Concurrent Mark Sweep Garbage Collector Logs पृष्ठ जीसी लॉग की व्याख्या करने में सहायक होना चाहिए।

अंत में, ओपी का निष्कर्ष यह है कि यह एक "विखंडन" समस्या है, और (आईएमओ) प्रदान किए गए सबूतों के स्निपेट द्वारा असमर्थित है। यह शायद कुछ और है।

स्रोत

2009-08-10 06:57:14

दिन में एक या दो बार कई मिनट लगते हैं। एक qustion संपादित किया। – Vitaly

मैं vmstat 5 का प्रयास करूंगा, धन्यवाद – Vitaly

हां, मैं वर्बोज़ जीसी आउटपुट का प्रयास करूंगा। यह सिर्फ बहुत अधिक जानकारी प्रिंट करता है - सर्वर धीमा कर सकता है, ऐसा नहीं करना चाहता :) अब हम GarbageCollectorMXBeans का उपयोग करते हैं। आउटपुट इस तरह दिखता है: ConcurrentMarkSweep 27459. और अंतराल लगभग पूरी तरह से इसके साथ मेल खाता है (27 सेकंड)। यह हर घंटे या तो होता है, यही कारण है कि मैं स्मृति विखंडन के बारे में सोचता हूं, स्मृति स्मृति नहीं।- विटाली 0 सेकंड पहले [इस टिप्पणी को हटाएं] – Vitaly

मैंने इस प्रकार की समस्या के लिए अच्छे प्रभाव के लिए YourKit का उपयोग किया है।

स्रोत

2009-08-10 06:37:46

हां, एक अच्छा उपकरण। लेकिन यह स्मृति विखंडन नहीं दिखाता है - केवल स्मृति खपत, जो यह झटके से मदद नहीं करता है। या मुझे कुछ अच्छे विकल्प नहीं पता :)? – Vitaly

आपकीकिट और अन्य मेमोरी प्रोफाइलर्स आपको दिखाएंगे कि स्मृति को पुनर्गठित करने और विखंडन को कम करने के प्रयास में जीसी कितनी बार हो रही है। यह आपको सीधे आपके विखंडन को नहीं दिखाएगा (जब तक मुझे एक अच्छा विकल्प भी नहीं पता) –

मैं विजुअलVM के माध्यम से जीसी के व्यवहार की जांच करने जा रहा हूं। वैसे, आपका सर्वर उत्पादन सर्वर पर चलाने के लिए खतरनाक है। हमें "अक्षम सभी" विकल्प के साथ भी प्रदर्शन के साथ समस्याएं थीं। और बड़ी वस्तुओं के बारे में सलाह के लिए धन्यवाद। – Vitaly

-4

जावा में कोई स्मृति विखंडन नहीं है; जीसी चलाने के दौरान, स्मृति क्षेत्रों को संकुचित किया जाता है।

चूंकि आपको उच्च CPU उपयोग नहीं दिखाई देता है, इसलिए कोई भी जीसी चल रहा है, या तो। तो कुछ और आपकी समस्याओं का कारण होना चाहिए।यहाँ कुछ विचार कर रहे हैं:

तो अपने आवेदन के डेटाबेस एक अलग सर्वर पर है, वहाँ नेटवर्क समस्याओं हो सकता है
आप Windows चलाने के लिए और आप नेटवर्क ड्राइव, ड्राइव मैप किया गया है आपके कंप्यूटर को लॉक कर सकता है (फिर नेटवर्क समस्याएं)। यूनिक्स पर एनएफएस ड्राइव के लिए भी यही सच है। नेटवर्क त्रुटियों के लिए सिस्टम लॉग की जांच करें।
कंप्यूटर डिस्क पर डेटा के बहुत सारे अदला-बदली है? चूंकि सीपीयू का उपयोग कम है, इसलिए समस्या का कारण यह हो सकता है कि ऐप को डिस्क पर बदल दिया गया था और जीसी रन ने इसे वापस रैम में मजबूर कर दिया था। यदि पूरे सर्वर में रैम में पूरे जावा ऐप को रखने के लिए पर्याप्त वास्तविक RAM नहीं है तो इसमें काफी समय लगेगा।

इसके अलावा, अन्य प्रक्रियाएं ऐप को रैम से बाहर कर सकती हैं। असली मेमोरी उपयोग और अपने स्वैप स्पेस उपयोग की जांच करें।

जीसी लॉग के उत्पादन में समझने के लिए, this post मदद कर सकता है।

[संपादित करें] मैं अभी भी चारों ओर "कम सीपीयू" और "जी सी स्टालों" मेरे सिर नहीं मिल सकता है। वे दोनों आम तौर पर एक-दूसरे से विरोधाभास करते हैं। यदि जीसी रुक रहा है, तो आपको 100% सीपीयू उपयोग देखना होगा। अगर सीपीयू निष्क्रिय है, तो कुछ और जीसी को अवरुद्ध कर रहा है। क्या आपके पास ऑब्जेक्ट्स हैं जो finalize() अधिभारित करते हैं? यदि अंतिम रूप से ब्लॉक होते हैं, तो जीसी हमेशा के लिए ले सकता है।

स्रोत

2009-08-10 07:54:09

वैसे विखंडन है, लेकिन जीसी इसे चलाने के दौरान इसे कम करने का प्रयास करेगा। बहुत अधिक बड़े-आश (आपके उपलब्ध ढेर के सापेक्ष) ऑब्जेक्ट्स जिन्हें अक्सर आवंटित/हटाया जाता है, ऐप को जीसी में काफी समय बिताने और प्रदर्शन को नुकसान पहुंचाने का कारण बनता है। –

यदि ConcurrentMarkAndSweep का उपयोग किया जाता है तो एक स्मृति विखंडन होता है। उदाहरण के लिए, http://publib.boulder.ibm.com/infocenter/wasinfo/v6r0/index.jsp?topic=/com.ibm.websphere.base.doc/info/aes/ae/rprf_javamemory.html। – Vitaly

कोई डेटाबेस इस्तेमाल नहीं किया गया। – Vitaly

विटाली, विखंडन समस्या है। मेरा अवलोकन: यदि ऑब्जेक्ट्स का छोटा आकार अक्सर अद्यतन होता जा रहा है तो उस स्थिति में यह बहुत कचरा उत्पन्न करता है। हालांकि सीएमएस इन वस्तुओं द्वारा कब्जा कर लिया गया स्मृति एकत्र करता है, यह स्मृति खंडित है। अब मार्क-स्वीप-कॉम्पैक्ट थ्रेड तस्वीर में आता है (दुनिया को रोकें) और लंबे खंड के कारण इस खंडित स्मृति को कॉम्पैक्ट करने का प्रयास करें।

इसके विपरीत यदि ऑब्जेक्ट का आकार बड़ा होता है तो यह कम खंडित स्मृति उत्पन्न करता है और
मार्क-स्वैप-कॉम्पैक्ट को इस स्मृति को कॉम्पैक्ट करने में कम समय लगता है। इससे कम थ्रूपुट हो सकता है लेकिन जीसी कॉम्पैक्शन के कारण लंबे विराम को कम करने में आपकी मदद मिलेगी।

स्रोत

2009-09-16 13:06:41

को संभाल सकता है हमने पहले से ही समस्या को संभाला है। कभी-कभी युवा जीन से बचने वाली वस्तुओं की प्रतिलिपि बनाने के लिए पुरानी उम्र में पर्याप्त स्मृति नहीं थी। सीएमएस शुरू होने पर निश्चित मात्रा में खपत की गई समस्या ने समस्या को हल किया। – Vitaly

विटाली, क्या आप संक्षेप में विखंडन समस्या हल करने के तरीके को इंगित कर सकते हैं? निश्चित राशि का उपभोग करने के बाद आपने सीएमएस को कितनी बार ट्रिगर किया? और यह विखंडन समस्या को कैसे हल करता है? किशोर –

कृपया पैसा पढ़ें == स्मृति –

-1

देखने के लिए कैसे विटाली शायद इस संभाला, Understanding Concurrent Mark Sweep Garbage Collector Logs देखते हैं।

स्रोत

2009-12-11 12:18:34

निम्न स्तर की निगरानी के लिए उपयोग करना चाहते हैं जाएगा इस -XX:PrintFLSStatistics=1 (या अधिक अवरुद्ध लागत पर अधिक के लिए यह 2 बनाना)। यह अनियंत्रित है और कभी-कभी आपको कुछ आंकड़े देता है। दुर्भाग्यवश यह विभिन्न कारणों से अधिकांश अनुप्रयोगों में बहुत उपयोगी नहीं है, लेकिन यह कम से कम ballpark-उपयोगी है।

आप उदाहरण

Max Chunk Size: 215599441

के लिए देख सकते हैं और इस

Total Free Space: 219955840

की तुलना और फिर न्यायाधीश करने औसत ब्लॉक आकार और ब्लॉक की संख्या के आधार पर विखंडन सक्षम होना चाहिए।

स्रोत

2013-05-09 21:36:02

यह पता लगाने में एक कठिन समस्या है।जब से मैं एक प्रणाली में कुछ समय खर्च करते हैं यह पता लगाना और साबित करने के लिए, मुझे जो किसी भी संकुचित कचरा कलेक्टर

हमारा नहीं था परिदृश्य में जहाँ यह हुआ

हम जावा 6, का उपयोग कर के साथ फंस गया बाहर सूचीबद्ध करते था आवेदन बहुत ज्यादा जीसी ज्यादातर युवा पीढ़ी संग्रह और कुछ बड़े पुराने पीढ़ी collecition
हमारे ढेर आकार था कर रहा था सुंदर big- मुख्य समस्या यह है (हम कम है, लेकिन हमारे आवेदन भी कई तार और संग्रह पर guzzling था)

समस्या प्रकट हुई डब्ल्यू क्योंकि हमारे सिस्टम में केवल एक विशेष एल्गोरिदम धीमा चल रहा था; बाकी सभी जो एक ही समय में चल रहे थे, काफी सामान्य रूप से चल रहे थे। इसने पूर्ण जीसी से इंकार कर दिया; इसके अलावा हम जीसी, थ्रेड डंप + जीसी लॉग को पूंछ करने के लिए jstat और अन्य j ** टूल का उपयोग कर रहे थे।

कुछ समय के लिए उठाए गए जेस्टैक थ्रेड डंप से, हम एक विचार प्राप्त कर सकते हैं कि कौन सा कोड ब्लॉक वास्तव में धीमा था। तो संदेह विखंडन ढेर गिर गया।

परीक्षण करने के लिए मैंने एक सरल कार्यक्रम लिखा है जिसमें दो सूची एक ऐरेलिस्ट और एक लिंक्डलिस्ट शुरू की गई है और आकार बदलने के कारण संचालन जोड़ा गया है। यह परीक्षण मैं आरईएसटी हैंडल के माध्यम से निष्पादित कर सकता हूं। आम तौर पर बहुत अंतर नहीं होता है। लेकिन एक खंडित ढेर के अंदर समय में एक स्पष्ट अंतर देखा जाता है; ऐरेलिस्ट के साथ एक बड़ा संग्रह आकार बदलता सूची से बहुत धीमा हो जाता है। ये समय लॉग किए गए थे, और खंडित सिर की तुलना में इसके लिए कोई अन्य स्पष्टीकरण नहीं था।

जावा 7 के साथ, हम जीसी ट्यूनिंग में बहुत सारे काम और अनुप्रयोगों में सुधार के साथ जी 1 जीसी में स्थानांतरित हुए; यहां ढेर कॉम्पैक्शन बहुत बेहतर है और यह बड़े ढेर को संभाल सकता है, हालांकि मुझे लगता है कि 16 जी ढेर से अधिक कुछ भी आपको उन जगहों पर ले जाएगा जहां आप वास्तव में जाना नहीं चाहते हैं- जीसी चूसने :)

स्रोत

2016-06-01 05:36:26

जावा में स्मृति विखंडन का विश्लेषण कैसे करें?

उत्तर

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