2012-10-10 28 views
11

मैं उत्पादन env पर मेरे अनुप्रयोग चलाने (RHEL 5.2 x64, ओरेकल JRE 1.7_05, बिल्ला 7.0.28) JVM तर्क के साथ:जावा OutOfMemory अपवाद: लोड हो रहा है ज़िप फ़ाइल पर mmap त्रुटि

-Xms8192m -Xmx8192m -XX:MaxPermSize=1024m 
-Doracle.net.tns_admin=/var/ora_net -XX:ReservedCodeCacheSize=512m -XX:+AggressiveOpts -XX:+UseFastAccessorMethods 
-XX:+UseStringCache -XX:+OptimizeStringConcat -XX:+UseCompressedOops -XX:+UseG1GC -Dcom.sun.management.jmxremote 
-Dcom.sun.management.jmxremote.port=9026 -Dcom.sun.management.jmxremote.ssl=false -Dcom.sun.management.jmxremote.authenticate=false 

कई समय के बाद मैं 'इस तरह मिल गया स्टैक ट्रेस किया है:

Java HotSpot(TM) 64-Bit Server VM warning: Attempt to deallocate stack guard pages failed. 
Java HotSpot(TM) 64-Bit Server VM warning: Attempt to allocate stack guard pages failed. 
mmap failed for CEN and END part of zip file 
[...] 
Caused by: java.lang.OutOfMemoryError: null 
    at java.util.zip.ZipFile.$$YJP$$open(Native Method) ~[na:1.7.0_05] 
    at java.util.zip.ZipFile.open(Unknown Source) ~[na:1.7.0_05] 
    at java.util.zip.ZipFile.<init>(Unknown Source) ~[na:1.7.0_05] 
    at java.util.zip.ZipFile.<init>(Unknown Source) ~[na:1.7.0_05] 
    at java.util.jar.JarFile.<init>(Unknown Source) ~[na:1.7.0_05] 
    at java.util.jar.JarFile.<init>(Unknown Source) ~[na:1.7.0_05] 
    at sun.net.www.protocol.jar.URLJarFile.<init>(Unknown Source) ~[na:1.7.0_05] 
    at sun.net.www.protocol.jar.URLJarFile.getJarFile(Unknown Source) ~[na:1.7.0_05] 
    at sun.net.www.protocol.jar.JarFileFactory.get(Unknown Source) ~[na:1.7.0_05] 
    at sun.net.www.protocol.jar.JarURLConnection.connect(Unknown Source) ~[na:1.7.0_05] 
    at sun.net.www.protocol.jar.JarURLConnection.getInputStream(Unknown Source) ~[na:1.7.0_05] 
    at java.net.URL.openStream(Unknown Source) ~[na:1.7.0_05] 
    at org.apache.catalina.loader.WebappClassLoader.findLoadedResource(WebappClassLoader.java:3279) ~[na:na] 
    at org.apache.catalina.loader.WebappClassLoader.getResourceAsStream(WebappClassLoader.java:1478) ~[na:na] 
    at org.apache.http.util.VersionInfo.loadVersionInfo(VersionInfo.java:242) ~[httpcore-4.2.jar:4.2] 
    at org.apache.http.impl.client.DefaultHttpClient.setDefaultHttpParams(DefaultHttpClient.java:180) ~[httpclient-4.2.jar:4.2] 
    at org.apache.http.impl.client.DefaultHttpClient.createHttpParams(DefaultHttpClient.java:158) ~[httpclient-4.2.jar:4.2] 
    at org.apache.http.impl.client.AbstractHttpClient.getParams(AbstractHttpClient.java:448) ~[httpclient-4.2.jar:4.2] 

मेरी प्रोफाइलर लिए देख रहे हैं - प्रत्येक भाग को ठीक (ढेर और गैर ढेर स्मृति 10% के लिए प्रयोग किया जाता) है और मुझे नहीं पता कि जहां समस्या है।

यह समस्या हर दिन एक ही समय में हो रही है और यह एप्लिकेशन अपटाइम से कनेक्ट नहीं है। इसका कारण क्या है?

संपादित:

लॉग फ़ाइल में नई उत्पादन:

Java HotSpot(TM) 64-Bit Server VM warning: CodeCache is full. Compiler has been disabled. 
Java HotSpot(TM) 64-Bit Server VM warning: Try increasing the code cache size using -XX:ReservedCodeCacheSize= 
Code Cache [0x00002aaaab790000, 0x00002aaaad240000, 0x00002aaacb790000) 
total_blobs=4223 nmethods=3457 adapters=707 free_code_cache=497085Kb largest_free_block=508887936 

लेकिन मैं पर्याप्त स्मृति है: http://i.stack.imgur.com/K8VMx.jpg

उत्तर: जावा संस्करण में समस्या। यह यहां वर्णित है: https://forums.oracle.com/forums/thread.jspa?messageID=10369413

उत्तर

4

मैं जब इस तरह की अदला-बदली में स्थान कम या अनुमति स्मृति मानचित्रण से बाहर चल रहा है के रूप में संसाधनों से बाहर चलाने से पहले इन त्रुटि देखा है। पर cat /proc/sys/vm/max_map_count

की तुलना में नीचे दी गई टिप्पणियां देखें।


मैं यह भी सुझाव दिया ....

आप YourKit साथ एक बग में चलाने प्रतीत होते हैं। आप कौन सा संस्करण उपयोग कर रहे हैं?

मैं आपके अधिकांश विकल्पों में कटौती करूंगा क्योंकि वे डिफ़ॉल्ट हैं और कुछ भी नहीं करते हैं या जटिलताओं को जटिल बना सकते हैं।

-mx8g -XX:MaxPermSize=1g -Doracle.net.tns_admin=/var/ora_net 
-XX:ReservedCodeCacheSize=512m -XX:+UseG1GC -Dcom.sun.management.jmxremote.port=9026 

मैं -XX:+UseG1GC छोड़ने के साथ ही इस एक अपेक्षाकृत नए कलेक्टर है की कोशिश करेंगे और अपने परिणामों परिवर्तन नहीं होना चाहिए।

+0

जिज्ञासा से, आप योरकिट भाग को कैसे समझते हैं? – Erik

+0

हाँ, मैं 'yjp-11.0.8' का उपयोग कर रहा हूं, लेकिन इससे पहले कि मैंने इसे इंस्टॉल किया है, समस्या तब होती है। मैं 'G1' कलेक्टर को छोड़ने की कोशिश करूंगा, लेकिन मुझे लगता है कि यह मेरी समस्या का समाधान नहीं करता है क्योंकि मैं लंबे समय तक' G1' के साथ काम करता हूं। इसके अलावा मुझे अभी एक समस्या है: [yjp_out] (http://my.jetscreenshot.com/demo/20121010-pnud-83kb)। –

+0

मैंने संसाधनों से बाहर होने से पहले इन त्रुटियों को देखा है जैसे स्वैप स्पेस से बाहर निकलना या अनुमत मेमोरी मैपिंग से बाहर चलना। 'सुडो बिल्ली/proc/$ पीआईडी ​​/ मानचित्र | पर एक नज़र डालें wc -l '' cat/proc/sys/vm/max_map_count' –

0

सुनिश्चित नहीं है कि जावा में क्या बदल गया है 1.7 जैसा कि मुझे जावा 1.6 से याद है, हम नीचे दिए गए एक्सएमएस विकल्पों का उपयोग करते हैं।

-Xms=512m -Xmx=512m 
+0

'-Xms8192m -Xmx8192m' जावा 1.6 में सही वाक्यविन्यास है। – Erik

0

इन विकल्पों

-Xrunhprof:heap=all,depth=12,cutoff=0 

यह आवेदन जड़ में एक डंप फ़ाइल उत्पन्न करेगा। बाद में आप HP Jmeter के साथ विश्लेषण कर सकते हैं। यह आपके 8Gigs स्मृति के साथ क्या हुआ एक स्नैप शॉट देगा। आप एचपी जेएमटर मैनुअल here देख सकते हैं।

ने भी अपने Xrunhprof विकल्पों को बुद्धिमानी से चुना है। मैंने उपर्युक्त विकल्प का उल्लेख किया है जो बड़ी डंप फ़ाइल उत्पन्न करेगा। मैनुअल से आप उपयुक्त विकल्प पा सकते हैं।

0

original blog article में से कुछ पैराग्राफ, यह बताते हैं कि कैसे जावा जार/ज़िप काम करता है:

OOM त्रुटि लोड करने के लिए जावा JDK zipfile से एक देशी कॉल (ZipFile.open (मूल निवासी विधि)) के दौरान शुरू हो रहा है हमारे आवेदन ईएआर फ़ाइल। इस मूल जेवीएम ऑपरेशन को इसके लोडिंग ऑपरेशन को निष्पादित करने के लिए उचित देशी मेमोरी और वर्चुअल एड्रेस स्पेस उपलब्ध है। इस बिंदु पर निष्कर्ष यह था कि हमारा जावा वीएम 1.5 तैनाती के समय देशी स्मृति/आभासी पता स्थान से बाहर चला रहा था।

सन जावा वी एम देशी स्मृति और mmap फ़ाइलों

JDK 1.4/1.5, किसी भी जार/ज़िप जावा वी एम द्वारा लोड फ़ाइल का उपयोग करते समय एक पता स्थान में पूरी तरह से मैप किया गया मिलता है। इसका मतलब यह है कि आप एक ही जेवीएम में अधिक ईएआर/जेएआर फाइल लोड कर रहे हैं, उच्चतर आपकी जावा प्रक्रिया की मूल स्मृति पदचिह्न है।

इसका यह भी अर्थ है कि आपका जावा हीप और पर्मजेन स्पेस जितना अधिक होगा; आपकी मूल मेमोरी रिक्त स्थान जैसे सी-हीप और एमएमएपी फाइलों के लिए निचली मेमोरी छोड़ी गई है जो निश्चित रूप से एक समस्या हो सकती है यदि आप 32-बिट जावा प्रक्रिया में बहुत से अलग एप्लिकेशन (ईएआर फाइल) को तैनात कर रहे हैं।

कृपया ध्यान दें कि सूर्य जेडीके 1.6 (मस्तंग) में सुधार के साथ आया और व्यवहार को बदल दिया ताकि JAR फ़ाइल की केंद्रीय निर्देशिका अभी भी मैप की गई हो, लेकिन प्रविष्टियां स्वयं अलग-अलग पढ़ी जाती हैं; देशी स्मृति आवश्यकता को कम करना।

मेरा सुझाव है कि आप इस तरह के जेडीके 1.4/1.5 सीमा पर अधिक विस्तार के लिए नीचे सूर्य बग आईडी लिंक की समीक्षा करें। http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6280693