जीसी ठहराव से कैसे निपटें

इस विषय में, हम उन कारणों के बारे में बात करेंगे जो कचरा कलेक्टर के लंबे ठहराव का कारण बनते हैं और उनसे कैसे निपटना है। मैं सीएमएस (कम ठहराव) के बारे में बात करूंगा, क्योंकि इस समय यह बड़ी मेमोरी और कम अक्षांश आवश्यकताओं वाले अनुप्रयोगों के लिए सबसे अधिक बार उपयोग किया जाने वाला एल्गोरिदम है। विवरण इस धारणा पर दिया गया है कि आपका एप्लिकेशन एक बड़ी मात्रा में मेमोरी और प्रोसेसर की एक बड़ी संख्या के साथ एक बॉक्स पर घूम रहा है।



विशेष रूप से जीसी और सीएमएस के संचालन के सामान्य सिद्धांत यहां विस्तार से वर्णित हैं । मैं केवल संक्षेप में यहाँ प्रस्तुत करता हूं कि हमें इस विषय को समझने की क्या आवश्यकता है:

• स्मृति को दो क्षेत्रों यंगजेन और ओल्डगेन में विभाजित किया गया है
• यंगजेन की नई बनाई गई वस्तुएं
• ओल्डगेन को ऐसी वस्तुएं मिलती हैं जो कई छोटे कचरा संग्रह से बच जाती हैं
• माइनर कचरा संग्रह यंगजेन को साफ करता है
• प्रमुख कचरा संग्रह ओल्डगेन को साफ करता है
• पूर्ण जीसी दोनों क्षेत्रों को साफ करें
• स्टॉप-द-वर्ल्ड का मतलब है कि कचरा संग्रह चल रहा है, तो आपका आवेदन पूरी तरह से बंद हो गया है
• समवर्ती एल्गोरिदम और चरण एप्लिकेशन को रोकने का कारण नहीं बनते हैं, अर्थात्। कचरा संग्रह अनुप्रयोग के समानांतर चलता है
• समानांतर एल्गोरिदम और चरण कई थ्रेड्स में काम करने वाली गतिविधियाँ हैं। वे समवर्ती या स्टॉप-द-वर्ल्ड हो सकते हैं। जब तक स्पष्ट रूप से कहा गया है, आमतौर पर प्रलेखन का मतलब है दुनिया भर में बिल्कुल रोक।
• मामूली कचरा संग्रह (मामूली जीसी) - हमेशा बस स्टॉप-द-वर्ल्ड
• फुल जीसी दुनिया-भर में रोक है
• CMS (समवर्ती मार्क स्वीप) के निम्नलिखित मुख्य चरण हैं:
  
  • प्रारंभिक निशान - stop-the-world
  • चिह्न - समवर्ती
  • preclean - समवर्ती
  • टिप्पणी - बंद करो दुनिया
  • स्वीप - समवर्ती
  
  
• मृत कचरा वस्तुओं के लिए खोज (जिसके लिए आवेदन में कोई लिंक नहीं हैं) पारंपरिक कचरा संग्राहकों में सभी जीवित वस्तुओं की खोज करके किया जाता है (जो जीसी जड़ों के लिंक के माध्यम से उपलब्ध हैं)
• CMS मेमोरी को डीफ़्रैग्मेन्ट नहीं करता है और इसे प्रबंधित करने के लिए मुफ्त सूचियों का उपयोग करता है।
• जीसी एर्गोनोमिक (वांछित अधिकतम ठहराव निर्दिष्ट करने वाले पैरामीटर) सीएमएस के साथ काम नहीं करता है

इसलिए, हमारे मामले में, हमारे पास निम्नलिखित क्षण हैं जब हमारा आवेदन पूरी तरह से बंद हो जाता है।

1. मामूली कचरा संग्रह
2. Init-mark सीएमएस चरण
3. रिमार्क चरण सीएमएस
4. फुल जी.सी.

पहले आपको यह निर्धारित करने की आवश्यकता है कि क्या इन चार मामलों में ठहराव इतने बड़े हैं कि वे आपके आवेदन के जीवन को खराब करते हैं। उत्पादन प्रणाली को देखना सभी के लिए बेहतर है, क्योंकि ठीक वही स्थितियाँ हैं जिनकी आपको आवश्यकता है। भगवान का शुक्र है कि जेएमएम को निम्न मापदंडों के साथ लॉन्च करके प्रदर्शन में गिरावट के बिना पूरी तरह से किया जा सकता है।

-verbose:gc
-Xloggc:gc.log
-XX:+PrintGCDetails
-XX:+PrintGCTimeStamps
-XX:+PrintGCApplicationStoppedTime

सीएमएस लॉग कैसे पढ़ें, इस पर विवरण यहां पाया जा सकता है । यदि आप चाहते हैं कि jvm की शुरुआत से संबंधित सेकंड में समय न छपे, लेकिन मानवीय रूप से, आप उस पार्सर का उपयोग कर सकते हैं, जिसे मैंने अजगर में लिखा था । अब हम केवल स्टॉप-द-वर्ल्ड इवेंट्स के लॉग के कुछ हिस्सों में रुचि रखते हैं।

1. मामूली कचरा संग्रहण को धीमा करता है।

[GC [DefNew: 209100K->25808K(235968K), 0.0828063 secs] 209100K->202964K(1284544K), 0.0828351 secs] [Times: user=0.02 sys=0.08, real=0.08 secs]
Total time for which application threads were stopped: 0.0829205 seconds

छोटी असेंबली के लिए मुख्य एल्गोरिथ्म नकल कर रहा है, इसलिए YougGen में अधिक जीवित वस्तुएं, अब छोटी असेंबली काम करती है। मैं कम से कम तीन चीजों को देखता हूं जब पोज बहुत लंबा हो जाता है और आप खुश नहीं होते हैं।

एक। आपका JVM एक अनुपयुक्त एल्गोरिथ्म का उपयोग करता है। उपरोक्त लॉग एकल-थ्रेडेड एल्गोरिथ्म (DefNew) का उपयोग करता है। मैं एक नए बहु-थ्रेडेड एल्गोरिथ्म (लॉग में इसे ParNew कहा जाएगा) की कोशिश करने की सलाह देता हूं, जिसे जबरन -XX: + UseParNewGC पैरामीटर के साथ चालू किया जा सकता है। आप यह भी उल्लेख कर सकते हैं कि यदि आप लॉग में PSYoungGen नाम देखते हैं, तो इसका मतलब है कि आपका JVM एक समानांतर एल्गोरिथ्म का उपयोग करता है, लेकिन एक पुराना कार्यान्वयन। हालाँकि CMS के साथ युग्मित, यह उपलब्ध नहीं है।

ख। आपने यंगगेन के लिए मेमोरी का एक बड़ा हिस्सा आवंटित किया है (दिए गए लॉग में यह 235968K है)। -Xmn पैरामीटर सेट करके इसे कम किया जा सकता है।

सी। आप वस्तुओं के लिए एक बड़ी अनुमत आयु के साथ बहुत बड़े उत्तरजीवी स्थान का उपयोग कर रहे हैं, इसलिए वस्तुओं को वापस वहीं कॉपी किया जाता है और एक अनावश्यक मामूली जीसी लोड देते हुए ओल्डगेन में नहीं फंस सकते। यह स्थिति -XX: SurvivorRatio और -XX: MaxTenuringThreshold मापदंडों के साथ ठीक की जा सकती है। इस मामले के अधिक विस्तृत विश्लेषण के लिए, आप जीसी लॉग्स में ऑब्जेक्ट्स की पीढ़ियों के बारे में अधिक जानकारी प्राप्त करने के लिए JVM को -XX: + PrintTenuringDistribution पैरामीटर के साथ चला सकते हैं।

2. init-mark लंबे समय तक काम करता है

[GC [1 CMS-initial-mark: 680168K(1048576K)] 706792K(1284544K), 0.0001161 secs] [Times: user=0.00 sys=0.00, real=0.00 secs]
Total time for which application threads were stopped: 0.0002740 seconds

इस चरण में, कचरा कलेक्टर जीसी रूट्स से सभी वस्तुओं को सीधे एक्सेस करता है। यदि आपने देखा कि इस चरण में बहुत समय लगता है, तो शायद आपके पास स्थानीय चर और स्थिर क्षेत्रों से बहुत अधिक लिंक हैं।

यहां आप इस चरण में भाग लेने वाले थ्रेड्स (ParallelCMSThreads) की संख्या बढ़ाने का प्रयास कर सकते हैं। डिफ़ॉल्ट रूप से, इसकी गणना (ParallelGCThreads + 3) / 4) के रूप में की जाती है। यानी यदि Par समानांतरGCThreads = 8, तो केवल दो धागे init-mark चरण में भाग लेंगे, जो कि समानता के कारण उत्पन्न होने वाले ओवरहेड के कारण कोई विशेष वृद्धि नहीं दे सकता है।

3. रिमार्क चरण में बड़े विराम

[GC[YG occupancy: 26624 K (235968 K)][Rescan (non-parallel) [grey object rescan, 0.0056478 secs][root rescan, 0.0001873 secs], 0.0059038 secs][weak refs processing, 0.0000090 secs] [1 CMS-remark: 750825K(1048576K)] 777449K(1284544K), 0.0059808 secs] [Times: user=0.00 sys=0.00, real=0.01 secs]
Total time for which application threads were stopped: 0.0061668 seconds

मार्क चरण के दौरान, एक विशेष प्रक्रिया चलती है जो सभी लिंक परिवर्तनों की निगरानी करती है। सभी बदले हुए लिंक को देखने के लिए केवल रिमार्क चरण की आवश्यकता है।

एक। यदि आप लॉग में "रेस्कैन (गैर-समानांतर)" वाक्यांश देखते हैं, तो मैं सुझाव देता हूं कि आप इस चरण के लिए कई थ्रेड्स को सक्षम करने के लिए -XX: + CMSParallelR एन्क्रिप्शनEnabled विकल्प को सक्षम करें।

ख। चूंकि इस चरण में सप्ताह के संदर्भ को बिल्कुल साफ कर दिया गया है, तो देखें कि क्या आप उनमें से कई का उपयोग करते हैं। (जैसे java.util.WeakHashMap)

सी। शायद आपके लिंक बहुत बदल रहे हैं। देखें कि कितने समय के दौरान inital-mark और टिप्पणी के बीच बीतता है। इन चरणों के बीच कम समय बीत चुका है, कम लिंक को बदल दिया जाएगा और तेजी से इसकी टिप्पणी समारोह। टिप्पणी चरण से ठीक पहले पांचवें जावा के साथ शुरू, गर्भपात-प्रीक्लीन चरण जोड़ा गया था, जो अनिवार्य रूप से कुछ भी नहीं करता है, मैं बस लटका रहता है और तब तक इंतजार करता है जब तक कि मामूली विधानसभा काम नहीं करती है, फिर यह थोड़ा लंबा इंतजार करता है और समाप्त होता है, इस प्रकार अगला चरण शुरू होता है। इस तर्क के दो कारण हैं। पहली टिप्पणी भी यंगगेन को स्कैन करती है और बहु-थ्रेडेड मोड में काम करने की संभावना के लिए, एक छोटी सी असेंबली की आवश्यकता होती है, जिसके बाद यंगगेन में शेष वस्तुओं को समानांतर प्रसंस्करण के लिए प्रभावी ढंग से विभाजित करना संभव हो जाता है। और दूसरा एक उल्लेखनीय रूप से लंबे समय तक काम करने का चरण है, और यदि यह मामूली निर्माण के ठीक बाद काम करता है, तो आपको एक बड़ा लंबा रोक दिया जाता है। ऐसे कई पैरामीटर हैं जो आपको इस व्यवहार को नियंत्रित करने की अनुमति देते हैं: CMSScheduleRemarkEdenSizeThreshold, CMSScheduleRemarkEdenPenetration, CMSMaxAbortablePrecleanTime। मेरा सुझाव है कि CMSScavengeBeforeRemark की कोशिश करें, जिससे एक छोटी सभा को टिप्पणी से तुरंत पहले बुलाया जाएगा। इस प्रकार, आप init-mark और टिप्पणी के बीच के समय को यथासंभव कम कर देंगे और टिप्पणी चरण के लिए कम काम होगा। यह विशेष रूप से प्रभावी होगा यदि छोटी विधानसभाओं के ठहराव टिप्पणी की तुलना में बहुत कम हैं, जो आमतौर पर होता है।

4. लॉग में पूर्ण जीसी

(concurrent mode failure): 798958K->74965K(1048576K), 0.0270334 secs] 1033467K->74965K(1284544K), [CMS Perm : 3022K->3022K(21248K)], 0.0270963 secs] [Times: user=0.03 sys=0.00, real=0.03 secs]
Total time for which application threads were stopped: 0.0271630 seconds

यह और कई अन्य मामलों में पूर्ण जीसी के कारण मैं पहले ही यहां विस्तार से वर्णन कर चुका हूं।

यही सब मैं विराम के बारे में कहना चाहता था। अरे हाँ, कृपया वृद्धिशील सीएमएस (-XX: + CMSIncrementalMode) का उपयोग न करें, जब तक कि आपके पास एक या दो कर्नेल न हों। सब कुछ केवल अधिक धीरे-धीरे काम करेगा।

और अन्य एल्गोरिदम के बारे में कुछ शब्द।

गारबेज फर्स्ट (G1), जो कि डिफ़ॉल्ट रूप से जावा 7 में दिखाई देता है और छठे जावा में इसे सक्षम करना संभव है, जावा एसई 6 अपडेट 14 से विकल्प -XX: + UnlockExperimentalVMOptions औरXXX + + UseG1GC के साथ शुरू होता है। विचार पूरे क्षेत्र को स्मृति के छोटे वर्गों में विभाजित करने के लिए है जो समय के विभिन्न वर्गों में एकत्र किए जा सकते हैं, जिससे बहुत छोटे ठहराव हो सकते हैं। विभिन्न जेवीएम पैरामीटर हैं जो आपको वांछित ठहराव सेट करने की अनुमति देते हैं, जिसके आधार पर मेमोरी को क्षेत्रों में विभाजित किया जाता है। यह ध्यान दिया जाना चाहिए कि इस दृष्टिकोण को सार्वभौमिक नहीं कहा जा सकता है, क्योंकि इसकी प्रभावशीलता स्मृति में वस्तुओं की टोपोलॉजी पर बहुत निर्भर करती है। यदि आप सक्रिय रूप से विभिन्न कैश का उपयोग करते हैं, तो जिन वस्तुओं में आपके पूरे एप्लिकेशन में लिंक बिखरे हुए हैं, तो एक कैविटी की असेंबली बड़ी संख्या में अन्य क्षेत्रों के स्कैन के साथ खींच सकती है, जिसके कारण ध्यान देने योग्य ठहराव होंगे।

हाल ही में, मैं अक्सर अज़ुल जीसी के बारे में पोस्ट पर आया हूं, जो वस्तुओं, आकार और स्मृति क्षेत्र की टोपोलॉजी की परवाह किए बिना सभी पर बिना रुके काम करता है। यह बहुत ही आशाजनक लगता है, लेकिन उनका समाधान लंबे समय से केवल अपने स्वयं के हार्डवेयर (अज़ुल के वेगा सिस्टम) पर उपलब्ध है, क्योंकि एल्गोरिथ्म को विशेष एलवीबी निर्देशों (लोड वैल्यू बैरियर) की आवश्यकता होती है। अच्छी खबर यह है कि अंत में इंटेल प्रोसेसर के x86-64 आर्किटेक्चर पर एक समान तंत्र को लागू करने का अवसर है। अगर मुझे स्क्रैच से अल्ट्रा-लो-लेटेंसी एप्लिकेशन लिखना है, तो मैं निश्चित रूप से इस जेवीएम का उपयोग करने पर विचार करूंगा, लेकिन अगर आपका आवेदन पहले से ही उत्पादन में है और इसकी स्थिरता सबसे महत्वपूर्ण आवश्यकताओं में से एक है, तो ओरेकल हॉटस्पॉट जेवीएम से किसी पर स्विच करें एक और जोखिम भरा कदम। आइए हम याद करते हैं कि उपयोगकर्ताओं को कितनी समस्याएं आईं, यहां तक ​​कि पांचवें से छठे जावा तक बढ़ रहा है।

विषय के लिंक:

1. आधिकारिक जावा मेमोरी प्रबंधन प्रलेखन
2. कचरा संग्रहकर्ता स्थापित करने पर श्वेत पत्र
   
3. जीसी पर काम करने वाले एक सूर्य कर्मचारी का ब्लॉग। यहां उन्होंने कचरा संग्रहण के विभिन्न पहलुओं का विस्तार से वर्णन किया है। मैं इसकी अत्यधिक अनुशंसा करता हूं।
   
4. JVM मेमोरी प्रबंधन के विभिन्न पहलुओं पर अक्सर पूछे जाने वाले प्रश्न
5. वैकल्पिक अज़ुल जीसी का विवरण। यह मौजूदा समाधानों की कमियों को भी इंगित करता है और बताता है कि उनके कारण क्या था।