उबंटू पर मेरी जावा प्रक्रिया को मारने में कुछ रहता है, किसी को पता है क्यों?

Question

तो हर दो दिनों में उबंटू पर मेरी जावा प्रक्रिया स्वचालित रूप से मारे जाती है, और मैं यह नहीं समझ सकता कि क्यों।

मेरे बॉक्स में 35.84 जीबी रैम है, जब मैं अपनी जावा प्रक्रिया लॉन्च करता हूं तो मैं इसे -Xmx28g पैरामीटर पास करता हूं, इसलिए इसे अधिकतम रैम से कम तरीके से उपयोग करना चाहिए।

मैं jstat भाग गया इस प्रकार है: jstat से उत्पादन का

# jstat -gccause -t `pgrep java` 60000 

पिछले कुछ लाइनों के ठीक पहले प्रक्रिया की मौत हो गई थी:

Time  S0  S1  E  O  P  YGC YGCT  FGC FGCT  GCT  LGCC     GCC 
14236.1 99.98 0.00 69.80 99.40 49.88 1011 232.305 11 171.041 403.347 unknown GCCause  No GC 
14296.2 93.02 0.00 65.79 99.43 49.88 1015 233.000 11 171.041 404.041 unknown GCCause  No GC 
14356.1 79.20 0.00 80.50 99.55 49.88 1019 233.945 11 171.041 404.986 unknown GCCause  No GC 
14416.2 0.00 99.98 24.32 99.64 49.88 1024 234.945 11 171.041 405.987 unknown GCCause  No GC 

यह वही है में नीचे चला गया प्रतीत हो रहा है/इस समय के आसपास var/log/syslog: https://gist.github.com/1369135

मेरे जावा ऐप के अलावा इस सर्वर पर वास्तव में कुछ भी नहीं चल रहा है। क्या चल रहा है?

संपादित करें: मैं जावा संस्करण 1.6.0_20 चला रहा हूं, स्टार्टअप पर जावा पर जा रहे एकमात्र उल्लेखनीय पैरामीटर "-सर्वर -Xmx28g" हैं। मैं एक एप्लिकेशन सर्वर का उपयोग नहीं कर रहा हूं लेकिन मेरा ऐप "सरल वेब ढांचे" को एम्बेड करता है।

Answer 1

(दूसरा प्रयास)।

समस्या को मानना ​​ओओएम हत्यारा है, फिर उसने ओएस को गंभीर स्मृति कमी संकट में काम करने के लिए एक बेताब प्रयास में अपनी प्रक्रिया को मार दिया है।

मुझे लगता है कि निष्कर्ष निकालना होगा:

• अपने JVM वास्तव में 28Gb की तुलना में काफी अधिक उपयोग कर रहा है; यानी आपके पास महत्वपूर्ण गैर-ढेर स्मृति उपयोग है, और

• ओएस को पर्याप्त मात्रा में स्वैप स्थान के साथ कॉन्फ़िगर नहीं किया गया है।

मैं अधिक स्वैप स्पेस जोड़ने की कोशिश करता हूं, ताकि ओएस आपातकाल में आपके आवेदन के कुछ हिस्सों को स्वैप कर सके।

वैकल्पिक रूप से, जेवीएम के ढेर आकार को कम करें।

---

ध्यान दें कि "-Xmx ..." अधिकतम ढेर आकार, नहीं स्मृति है कि आपके JVM उपयोग कर सकते हैं की अधिकतम राशि निर्धारित करता है। JVM ढेर के बाहर कुछ सामान रखता है, जिसमें थ्रेड स्टैक्स और मेमोरी-मैप की गई फ़ाइलों के लिए स्मृति जैसी चीजें शामिल हैं जो आपका एप्लिकेशन उपयोग कर रही हैं।

Answer 2

वाह, क्या आपके पास वास्तव में 28 जीबी ढेर हो सकता है ?! हो सकता है कि आपको इसे कम करने की कोशिश करनी चाहिए, मुझे लगता है कि रैम के 50% से अधिक नहीं (इसलिए ~ 18 जीबी, या यहां तक ​​कि 15 जीबी भी हो सकता है)। इसके अलावा 171 पूर्ण जीसी बहुत हैं! यह ऐप कब तक चल रहा था? 2-3 दिनों में 171 विशाल लगता है। बीटीडब्ल्यू जीआईटी समाप्त होने से पहले एक ओओएम इंगित करता है - मुझे लगता है कि ढेर को कम करने से यह ठीक हो जाएगा (आप मूल स्थान को विस्तारित करने से JVM को सीमित कर सकते हैं)। विभिन्न मानकों को समायोजित करने का प्रयास करें, यदि आवश्यक हो तो उदाहरण के लिए स्टैक आकार (-Xss) आज़माएं। अधिकतम परम आकार और अन्य अनुभागों को भी देखें। इसकी एक स्मृति समस्या है और यह आवश्यक रूप से ढेर नहीं हो सकता है।

Answer 3

आप किस जेवीएम का उपयोग कर रहे हैं? और क्या एप्लीकेशन सर्वर? यह संभव है कि आप बहुत अधिक मेमोरी आवंटित कर रहे हैं, और यह समस्याग्रस्त हो सकता है - कचरा कलेक्टर को अपना काम करने में परेशानी हो सकती है।

मुझे यकीन नहीं है कि यह आपका मामला है, लेकिन मुझे लिनक्स ओवरकैट्स मेमोरी के तरीके को समझाते हुए काफी रोचक this आलेख मिला।

Answer 4

ओओएम-किलर में आपका स्वागत है, एक लिनक्स 'फीचर' जो हर जगह बड़े-स्मृति अनुप्रयोगों का झुकाव है। सौदा करने के लिए कोई आसान नुस्खा नहीं है, बस इसके लिए Google और पढ़ने और हथियार शुरू करें।

जबकि मैं ओओएम हत्यारे के शख्सियत के संक्षिप्त स्पष्टीकरण पर अपनी मानसिक उंगलियां नहीं डाल सकता, मुझे याद है कि महत्वपूर्ण ट्यूनिंग पैरामीटर को 'स्वैपनेस' कहा जाता है। हमारे बड़े सर्वरों में से एक पर, हमने:

/etc/sysctl.conf:vm.swappiness=20

पढ़ें http://www.gentooexperimental.org/~patrick/weblog/archives/2009-11.html।

Answer 5

उबंटू की "वॉचडॉग" प्रक्रिया है जो स्मृति को कम होने पर अन्य प्रक्रियाओं को मार देती है। मैनपेज देखें: http://manpages.ubuntu.com/manpages/natty/man8/watchdog.8.html