हम एक जावा सर्वर लिनक्स 32-बिट (CentOS) पर सूर्य JRE 6u20 पर चल रहे हैं। हम (मैं केवल प्रासंगिक लोगों प्रदान की है) निम्नलिखित विकल्पों के साथ सीएमएस कलेक्टर के साथ सर्वर हॉटस्पॉट का उपयोग करें:त्रिशंकु JVM लेने वाली 100% सीपीयू
-Xmx896m -Xss128k -XX:NewSize=384M -XX:MaxPermSize=96m -XX:+UseParNewGC -XX:+UseConcMarkSweepGC
कभी कभी, कुछ समय से चल के बाद, JVM एक त्रिशंकु राज्य, जिससे भी में पर्ची करने लगता है हालांकि हम एप्लिकेशन को कोई अनुरोध नहीं करते हैं, सीपीयू 100% पर स्पिन जारी है (हमारे पास 8 लॉजिकल सीपीयू हैं, इसलिए ऐसा लगता है कि केवल एक सीपीयू कताई करता है)। इस हालत में JVM संकेतों (-3 मारने) SIGHUP का जवाब नहीं है और हम jstack साथ सामान्य रूप से इसे करने के लिए कनेक्ट नहीं कर सकता। हम "jstack -f" के साथ जुड़ सकते हैं, लेकिन उत्पादन कुशल है (हम JStack से NullPointerExceptions के बहुत सारे देख सकते हैं जाहिरा तौर पर, क्योंकि यह करने के लिए की पैदल दूरी पर 'कुछ ढेर में सक्षम नहीं था)। तो "jstack -F" आउटपुट बेकार लगता है।
हम हालांकि "gdb" से एक ढेर डंप चलने के बाद, और हम धागा आईडी कि सीपीयू spins मिलान करने में सक्षम थे (हमने पाया है कि "टॉप" का उपयोग कर एक प्रति-धागा दृश्य के साथ - "एच" विकल्प) के साथ एक सूत्र के ढेर कि gdb परिणाम में दिखाई देने और इस लिए कि यह कैसे की तरह लग रहा है:
Thread 443 (Thread 0x7e5b90 (LWP 26310)):
#0 0x0115ebd3 in CompactibleFreeListSpace::block_size(HeapWord const*) const() from /usr/java/jdk1.6.0_20/jre/lib/i386/server/libjvm.so
#1 0x01160ff9 in CompactibleFreeListSpace::prepare_for_compaction(CompactPoint*)() from /usr/java/jdk1.6.0_20/jre/lib/i386/server/libjvm.so
#2 0xc in Generation::prepare_for_compaction(CompactPoint*)() from /usr/java/jdk1.6.0_20/jre/lib/i386/server/libjvm.so
#3 0x01229b2c in GenCollectedHeap::prepare_for_compaction()() from /usr/java/jdk1.6.0_20/jre/lib/i386/server/libjvm.so
#4 0x0122a7fc in GenMarkSweep::invoke_at_safepoint(int, ReferenceProcessor*, bool)() from /usr/java/jdk1.6.0_20/jre/lib/i386/server/libjvm.so
#5 0x01186024 in CMSCollector::do_compaction_work(bool)() from /usr/java/jdk1.6.0_20/jre/lib/i386/server/libjvm.so
#6 0x011859ee in CMSCollector::acquire_control_and_collect(bool, bool)() from /usr/java/jdk1.6.0_20/jre/lib/i386/server/libjvm.so
#7 0x01185705 in ConcurrentMarkSweepGeneration::collect(bool, bool, unsigned int, bool)() from /usr/java/jdk1.6.0_20/jre/lib/i386/server/libjvm.so
#8 0x01227f53 in GenCollectedHeap::do_collection(bool, bool, unsigned int, bool, int)() from /usr/java/jdk1.6.0_20/jre/lib/i386/server/libjvm.so
#9 0x0115c7b5 in GenCollectorPolicy::satisfy_failed_allocation(unsigned int, bool)() from /usr/java/jdk1.6.0_20/jre/lib/i386/server/libjvm.so
#10 0x0122859c in GenCollectedHeap::satisfy_failed_allocation(unsigned int, bool)() from /usr/java/jdk1.6.0_20/jre/lib/i386/server/libjvm.so
#11 0x0158a8ce in VM_GenCollectForAllocation::doit()() from /usr/java/jdk1.6.0_20/jre/lib/i386/server/libjvm.so
#12 0x015987e6 in VM_Operation::evaluate()() from /usr/java/jdk1.6.0_20/jre/lib/i386/server/libjvm.so
#13 0x01597c93 in VMThread::evaluate_operation(VM_Operation*)() from /usr/java/jdk1.6.0_20/jre/lib/i386/server/libjvm.so
#14 0x01597f0f in VMThread::loop()() from /usr/java/jdk1.6.0_20/jre/lib/i386/server/libjvm.so
#15 0x015979f0 in VMThread::run()() from /usr/java/jdk1.6.0_20/jre/lib/i386/server/libjvm.so
#16 0x0145c24e in java_start(Thread*)() from /usr/java/jdk1.6.0_20/jre/lib/i386/server/libjvm.so
#17 0x00ccd46b in start_thread() from /lib/libpthread.so.0
#18 0x00bc2dbe in clone() from /lib/libc.so.6
यह है कि एक JVM धागा, जबकि कुछ सीएमएस संबंधित काम कर रही स्पिन हो रही है लगता है। हमने बॉक्स पर मेमोरी उपयोग की जांच की है, वहां पर्याप्त मेमोरी उपलब्ध है और सिस्टम स्वैपिंग नहीं कर रहा है। क्या कोई ऐसी स्थिति में आया है? क्या यह एक जेवीएम बग की तरह दिखता है?
अद्यतन
मैं इस समस्या (यह कि अधिक से अधिक 7 दिनों के लिए चल रहा है एक सर्वर पर फिर से हुआ) के बारे में कुछ और जानकारी प्राप्त कर लिया है। जब JVM ने "लटका" स्थिति दर्ज की, तो यह तब तक 2 घंटे तक रहा जब तक सर्वर मैन्युअल रूप से पुनरारंभ नहीं हुआ। हमने प्रक्रिया और जीसी लॉग का कोर डंप प्राप्त किया है। हमने एक हीप डंप भी प्राप्त करने की कोशिश की, लेकिन "jmap" विफल रहा। हमने jmap -F का उपयोग करने की कोशिश की लेकिन फिर एक अपवाद के साथ निरस्त कार्यक्रम से पहले केवल 4 एमबी फ़ाइल लिखी गई थी (स्मृति स्थान के बारे में कुछ सुलभ नहीं है)। अब तक मुझे लगता है कि सबसे दिलचस्प जानकारी जीसी लॉग से आता है। ऐसा लगता है कि जी सी लॉगिंग (संभवतः समय था जब वी एम धागा लंबे पाश में चला गया पर) के रूप में अच्छी तरह से बंद कर दिया:
657501.199: [Full GC (System) 657501.199: [CMS: 400352K->313412K(524288K), 2.4024120 secs] 660634K->313412K(878208K), [CMS Perm : 29455K->29320K(68568K)], 2.4026470 secs] [Times: user=2.39 sys=0.01, real=2.40 secs]
657513.941: [GC 657513.941: [ParNew: 314624K->13999K(353920K), 0.0228180 secs] 628036K->327412K(878208K), 0.0230510 secs] [Times: user=0.08 sys=0.00, real=0.02 secs]
657523.772: [GC 657523.772: [ParNew: 328623K->17110K(353920K), 0.0244910 secs] 642036K->330523K(878208K), 0.0247140 secs] [Times: user=0.08 sys=0.00, real=0.02 secs]
657535.473: [GC 657535.473: [ParNew: 331734K->20282K(353920K), 0.0259480 secs] 645147K->333695K(878208K), 0.0261670 secs] [Times: user=0.11 sys=0.00, real=0.02 secs]
....
....
688346.765: [GC [1 CMS-initial-mark: 485248K(524288K)] 515694K(878208K), 0.0343730 secs] [Times: user=0.03 sys=0.00, real=0.04 secs]
688346.800: [CMS-concurrent-mark-start]
688347.964: [CMS-concurrent-mark: 1.083/1.164 secs] [Times: user=2.52 sys=0.09, real=1.16 secs]
688347.964: [CMS-concurrent-preclean-start]
688347.969: [CMS-concurrent-preclean: 0.004/0.005 secs] [Times: user=0.00 sys=0.01, real=0.01 secs]
688347.969: [CMS-concurrent-abortable-preclean-start]
CMS: abort preclean due to time 688352.986: [CMS-concurrent-abortable-preclean: 2.351/5.017 secs] [Times: user=3.83 sys=0.38, real=5.01 secs]
688352.987: [GC[YG occupancy: 297806 K (353920 K)]688352.987: [Rescan (parallel) , 0.1815250 secs]688353.169: [weak refs processing, 0.0312660 secs] [1 CMS-remark: 485248K(524288K)] 783055K(878208K), 0.2131580 secs] [Times: user=1.13 sys
=0.00, real=0.22 secs]
688353.201: [CMS-concurrent-sweep-start]
688353.903: [CMS-concurrent-sweep: 0.660/0.702 secs] [Times: user=0.91 sys=0.07, real=0.70 secs]
688353.903: [CMS-concurrent-reset-start]
688353.912: [CMS-concurrent-reset: 0.008/0.008 secs] [Times: user=0.01 sys=0.00, real=0.01 secs]
688354.243: [GC 688354.243: [ParNew: 344928K->30151K(353920K), 0.0305020 secs] 681955K->368044K(878208K), 0.0308880 secs] [Times: user=0.15 sys=0.00, real=0.03 secs]
....
....
688943.029: [GC 688943.029: [ParNew: 336531K->17143K(353920K), 0.0237360 secs] 813250K->494327K(878208K), 0.0241260 secs] [Times: user=0.10 sys=0.00, real=0.03 secs]
688950.620: [GC 688950.620: [ParNew: 331767K->22442K(353920K), 0.0344110 secs] 808951K->499996K(878208K), 0.0347690 secs] [Times: user=0.11 sys=0.00, real=0.04 secs]
688956.596: [GC 688956.596: [ParNew: 337064K->37809K(353920K), 0.0488170 secs] 814618K->515896K(878208K), 0.0491550 secs] [Times: user=0.18 sys=0.04, real=0.05 secs]
688961.470: [GC 688961.471: [ParNew (promotion failed): 352433K->332183K(353920K), 0.1862520 secs]688961.657: [CMS
मैं इस समस्या पर शक लॉग में अंतिम पंक्ति के साथ कुछ है (मैं मैंने कुछ लाइनों को छोड़ने के लिए कुछ "...." जोड़ा जो दिलचस्प नहीं थे)। तथ्य यह है कि सर्वर 2 घंटे के लिए लटका राज्य में रुके थे (शायद जीसी करने की कोशिश कर और कॉम्पैक्ट वर्ष पीढ़ी) मेरे लिए काफी अजीब लगता है। साथ ही, जीसी लॉग अचानक उस संदेश के साथ बंद हो जाता है और कुछ भी और मुद्रित नहीं होता है, संभवतः क्योंकि वीएम थ्रेड किसी प्रकार के अनंत लूप (या कुछ 2 घंटे लगते हैं) में आता है।
यदि आप कम स्मृति स्थितियों में चल रहे हैं जो निरीक्षण करना असंभव नहीं है। लेकिन वीएम अपडेट करें, यू 21/22, आईआईआरसी में कुछ जीसी बड़े फिक्स थे। इसके अलावा MaxPermSize = 96m बहुत कम है, मुझे पता है कि आप क्या चलते हैं, हालांकि। – bestsss
मुझे पूरा यकीन है कि वीएम स्मृति में कम नहीं चल रहा है। जीसी लॉग से हर बार एक पूर्ण जीसी है, ओल्डजेन औसत 370 एमबी तक वापस आ जाता है, जिसका मतलब है कि इसमें 27% खाली स्थान है। युवा पीढ़ी (384 एमबी) प्रत्येक सफाई पर बहुत खाली है। तो मुझे लगता है कि बहुत मेमोरी है। यह समस्या पूर्ण जीसी चलने से ठीक पहले प्रतीत होती है (जैसा कि आप लॉग से देख सकते हैं) जब ओल्डजेन लगभग पूरा हो गया है और यंगगेन कलेक्टर कुछ वस्तुओं को बढ़ावा नहीं दे सकता है। शायद वीएम को पता चलता है कि ओल्डजेन बहुत खंडित है, इसलिए यह एक compaction ट्रिगर करता है (जो 2+ घंटे तक रहता है)। – Bogdan
विंडोज सर्वर 2008 पर सर्वर जेआरई 6u26 के साथ एक समान पैटर्न का निरीक्षण करना। सीएनएमएस संग्रह प्रविष्टि के उस खंड के बाद पैरान्यू पदोन्नति विफल: << 911188.231: [जीसी 911188.231: [परन्यू (पदोन्नति विफल): 750602 के-> 753650K (811008K), 3.7030115 सेकेंड] 911191.934: [सीएमएस >> पुरानी जेन उस बिंदु पर 161582K उपलब्ध थी, जो कि स्तरों के बराबर है जिस पर पहले सीएमएस संग्रह चलने लगे थे। आश्चर्य है कि क्या आपको कभी आपकी समस्या में कोई और अंतर्दृष्टि है, बोगदान? – Brant