जब एक आउटऑफमेमरी एरर

Question

फेंकने वाला JVM ठीक है, तो हम जावा एप्लिकेशन चला रहे हैं जो कभी-कभी "फ्रीज" होता है क्योंकि कुछ थ्रेड लगभग सभी ढेर का उपयोग कर रहे हैं। जेवीएम पूर्ण जीसी करने के बावजूद 60 सेकंड से अधिक समय तक एप्लिकेशन आउटऑफमेमरी एरर के साथ कभी नहीं मरता है।

मैं जावा प्रलेखन से पढ़ा है कि:

throughput कलेक्टर यदि बहुत अधिक समय कचरा संग्रहण कर खर्च किया जा रहा है एक बाहर के स्मृति अपवाद फेंक देते हैं। उदाहरण के लिए, यदि JVM कुल समय में 98% से अधिक कचरा संग्रह कर रहा है और ढेर के 2% से कम पुनर्प्राप्त कर रहा है, तो यह एक आउट-ऑफ-मेमोरी एक्सपेक्शन फेंक देगा।

मुझे इस 98% समय के बारे में अधिक जानकारी चाहिए (समय सीमा क्या है?), और यदि यह मान कम करना संभव है, यानी यदि आवेदन 9 0% खर्च कर रहा है तो ओओएमई फेंकना जीसी में समय और ढेर के 10% से अधिक मुक्त नहीं कर सकते हैं।

लक्ष्य यह सुनिश्चित करना है कि आवेदन मर जाएगा (ओओएमई के साथ केवल जीसी करने की बजाए) ताकि हम ओओएमई पर डंप उत्पन्न कर सकें।

यहाँ स्मृति और जीसी सेटिंग्स हम प्रयोग कर रहे हैं (ओएस सोलारिस है):

-Xms2048m -Xmx2048m \ 
-Xmn512m \ 
-XX:PermSize=256m 
-XX:MaxPermSize=256m \ 
-XX:+UseParNewGC 
-XX:ParallelGCThreads=16 \ 
-XX:+UseConcMarkSweepGC 
-XX:+CMSParallelRemarkEnabled \ 
-XX:+DisableExplicitGC \ 
-XX:+PrintGC 
-XX:+PrintGCDetails 
-XX:+PrintGCTimeStamps \ 
-XX:+PrintClassHistogram \ 
-Xloggc:/gcmonitor.log \ 
-XX:+HandlePromotionFailure \ 
-XX:SurvivorRatio=4 
-XX:TargetSurvivorRatio=90 
-XX:MaxTenuringThreshold=10 \ 
-XX:+UseTLAB 
-XX:TLABSize=32k 
-XX:+ResizeTLAB \ 
-XX:+UseMPSS \ 

Answer 1

मैं के बारे में अधिक जानकारी चाहते हैं क्या समय साधन के इस 98% (क्या समय सीमा है?)

इस प्रश्न का उत्तर दें: GC overhead limit exceeded सुझाव देता है कि यह 1 मिनट है।

, यह मान

एक बार फिर सवाल ऊपर उल्लेख किया है की जांच कर रहे कम करने के लिए संभव है आप GCTimeLimit और GCHeapFreeLimit पैरामीटर का उपयोग कर सकते हैं की तरह लग रहा है।

Answer 2

आप केवल हीप डंप के पक्ष लाभ प्राप्त करने के लिए एक OOM मजबूर करने के लिए देख रहे हैं, आप अब इस एक चल जावा प्रक्रिया पर किसी भी समय कर सकते हैं:

:

प्रक्रिया का पता लगाएं

JPS -v

एक डंप

jmap -dump बाध्य करें: फ़ाइल = heap.bin

फिर अपने पसंद के टूल में heap.bin का विश्लेषण करें।

Answer 3

ओओएमई पर या जेएमएपी के साथ इंटरैक्टिव रूप से एक हीप डंप लेना JVM को मिनटों के लिए रोक सकता है। कोर डंप मैन्युअल रूप से बनाने के लिए आमतौर पर गकोर का उपयोग करना अधिक प्रभावी होता है, फिर कोर से हीप डंप लेने के लिए jmap का उपयोग करें।

मैं अधिक ढेर आवंटित करता हूं, देखें कि इससे समस्या को कम करने में मदद मिलती है या नहीं।अत्यधिक जीसी ट्यूनिंग के बारे में भी सावधान रहें - आम तौर पर कलेक्टरों के पास उत्कृष्ट डिफॉल्ट होते हैं, मैं केवल Xloggc के बाद विकल्पों की अनुशंसा करता हूं यदि आपने यह निर्धारित किया है कि ये आपके अनुप्रयोग के ऑब्जेक्ट आवंटन/प्रतिधारण पैटर्न के आधार पर जीसी प्रदर्शन में काफी सुधार करते हैं। उपलब्ध हार्डवेयर धागे की संख्या के आधार पर समांतर संग्राहक धागे भी बहुत अधिक हो सकते हैं।

आप जीसी लॉग से ढेर के उपयोग के लिए पैटर्न निर्धारित करने में सक्षम होना चाहिए और यह निर्धारित करना चाहिए कि यह एक थ्रेड द्वारा तेजी से उपयोग किया जा रहा है, एक ऑपरेशन कर रहा है जो तेजी से ढेर को समाप्त करता है, या धीमे 'रिसाव' पैटर्न ऑब्जेक्ट्स को समय-समय पर प्रचारित किया जाता है जिससे कार्यकाल का सामना किया जा सकता है, कुछ ऑब्जेक्ट्स उम्मीदवारों के संग्रह के लिए - हिस्टोग्राम भी मदद करेगा।

जो भी कहा जाता है, एक ढेर डंप पर ध्यान केंद्रित करना निश्चित रूप से जाने का तरीका है। ग्रहण MAT सबसे अच्छा विश्लेषण उपकरण आईएमओ है। यहाँ शुरू करने के लिए एक बेहतरीन स्थान है अगर आप इसे से पहले इस्तेमाल नहीं किया है:

http://kohlerm.blogspot.com/2009/07/eclipse-memory-analyzer-10-useful.html