बहुत समय पहले ऐसा नहीं हुआ था, एक अत्यधिक भारित .NET सेवा में कचरा संग्रहण के Habré अनुकूलन पर एक उत्कृष्ट लेख दिखाई दिया। यह लेख इस मामले में बहुत दिलचस्प है कि लेखक, सिद्धांत से लैस, पहले असंभव था: उन्होंने जीसी के ज्ञान का उपयोग करके अपने आवेदन को अनुकूलित किया। और अगर पहले हमें पता नहीं था कि यह जीसी कैसे काम करता है, तो अब हम अपनी पुस्तक प्रो .NET मेमोरी मैनेजमेंट में कोनराड कोकोस के प्रयासों के माध्यम से चांदी के थाल पर हमें प्रस्तुत करते हैं। मैंने अपने लिए क्या निष्कर्ष निकाले हैं? आइए समस्या क्षेत्रों की एक सूची बनाते हैं और सोचते हैं कि उन्हें कैसे हल किया जाए।

हाल ही में CLRium # 5 कार्यशाला: कचरा कलेक्टर में, हमने पूरे दिन जीसी के बारे में बात की। हालाँकि, मैंने टेक्स्ट डिकोडिंग के साथ एक रिपोर्ट प्रकाशित करने का निर्णय लिया। यह अनुप्रयोग अनुकूलन के बारे में निष्कर्ष के बारे में बात है।

क्रॉस-जनरेशन कनेक्टिविटी को कम करें

समस्या

कचरा संग्रहण गति को अनुकूलित करने के लिए, GC जब भी संभव हो युवा पीढ़ी को इकट्ठा करता है। लेकिन ऐसा करने के लिए, उसे पुरानी पीढ़ियों से लिंक के बारे में भी जानकारी चाहिए (वे इस मामले में एक अतिरिक्त जड़ के रूप में कार्य करते हैं): कार्ड टेबल के।

उसी समय, युवा पीढ़ी के पुराने से एक लिंक आपको कार्ड तालिका के साथ क्षेत्र को कवर करने के लिए मजबूर करता है:

• 4 बाइट्स ओवरलैप 4 केबी या अधिकतम। 320 वस्तुओं - x86 वास्तुकला के लिए
• 8 बाइट्स ओवरलैप 8 केबी या अधिकतम। 320 वस्तुओं - x64 वास्तुकला के लिए

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

इसलिए युवा पीढ़ी में विरल संबंध जीसी को अधिक समय लेने वाले बना देंगे

निर्णय

• युवा पीढ़ी में कनेक्शन के साथ वस्तुओं का पता लगाएं - पास;
• यदि शून्य पीढ़ी की वस्तुओं का यातायात माना जाता है, तो पुलिंग का उपयोग करें। यानी वस्तुओं का एक पूल बनाएं (कोई नया नहीं होगा: शून्य पीढ़ी की कोई वस्तु नहीं होगी)। और आगे, लगातार दो GCs के साथ पूल को "वार्म अप" करके, ताकि इसकी सामग्री दूसरी पीढ़ी में विफल होने की गारंटी हो, आप इस तरह युवा पीढ़ी के लिंक से बचते हैं और कार्ड तालिका में शून्य होते हैं;
• युवा पीढ़ी के लिंक से बचें;

मजबूत कनेक्टिविटी से बचें

समस्या

SOH में वस्तुओं के संपीड़न के चरण के एल्गोरिदम से निम्नानुसार है:

• ढेर को संपीड़ित करने के लिए, आपको पेड़ के चारों ओर जाने और सभी लिंक की जांच करने की आवश्यकता है, उन्हें नए मूल्यों के लिए सही करना
• इसके अलावा, कार्ड तालिका से लिंक वस्तुओं के पूरे समूहों को प्रभावित करते हैं

इसलिए, वस्तुओं की सामान्य मजबूत कनेक्टिविटी जीसी के दौरान घटाव पैदा कर सकती है।

निर्णय

• पास की वस्तुओं को एक पीढ़ी में, दृढ़ता से जोड़ा है
• सामान्य रूप से अनावश्यक लिंक से बचें (उदाहरण के लिए, इसे कॉपी करने के बजाय-> लिंक को हैंडल करें, पहले से मौजूद इस का उपयोग करें-> सेवा-> हैंडल)
• छिपे हुए कनेक्टिविटी वाले कोड से बचें। उदाहरण के लिए, बंद

खंड के उपयोग की निगरानी करें

समस्या

गहन कार्य के दौरान, नई वस्तुओं के आवंटन में देरी होने पर स्थिति उत्पन्न हो सकती है: कचरे को साफ करते समय ढेर के नीचे नए खंडों का आवंटन और उनके आगे का अपघटन

निर्णय

• नए सेगमेंट के चयन बिंदुओं को नियंत्रित करने और उनके विघटन और विमोचन के लिए PerfMon / Sysinternal यूटिलिटीज का उपयोग करना
• यदि हम LOH के बारे में बात कर रहे हैं, जो एक घने बफर ट्रैफ़िक है, तो ArrayPool का उपयोग करें
• यदि हम SOH के बारे में बात कर रहे हैं, तो सुनिश्चित करें कि समान जीवनकाल की वस्तुओं को पास में हाइलाइट किया गया है, कलेक्ट के बजाय स्वीप प्रदान करते हैं
• SOH: ऑब्जेक्ट पूल का उपयोग करें

कोड के लोड किए गए अनुभागों में मेमोरी आवंटित न करें

समस्या

कोड का भरा हुआ खंड मेमोरी आवंटित करता है:

• नतीजतन, GC 1Kb की नहीं बल्कि 8Kb की आवंटन विंडो का चयन करता है।
• यदि खिड़की अंतरिक्ष से बाहर निकलती है, तो यह एक जीसी और बंद क्षेत्र का विस्तार करता है
• नई वस्तुओं की एक घनीभूत धारा अन्य थ्रेड्स से अल्पकालिक वस्तुओं को जल्दी से खराब कचरा संग्रह की स्थिति के साथ पुरानी पीढ़ी में चली जाएगी
• जिससे कचरा संग्रहण का समय बढ़ेगा
• जिससे समवर्ती मोड में भी दुनिया को अधिक समय तक रोका जा सकेगा

निर्णय

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

LOH में अनावश्यक मेमोरी आवंटन से बचें

समस्या

LOH में एरेज़ रखने से जीसी प्रक्रिया का विखंडन या भार होता है

निर्णय

• सरणियों के विभाजन का उपयोग उप-वर्गों में करें और एक ऐसा वर्ग जो इस तरह के सरणियों के साथ काम करने के तर्क को अलग करता है (अर्थात, सूची <टी> के बजाय, जहां मेगा-सरणी संग्रहीत है, सरणी के साथ इसका MyList [] [], सरणी को थोड़ा छोटा विभाजित करता है)
  
  • एरोस एसओएच जाएंगे
  • कूड़े के संग्रह के एक जोड़े के बाद, वे कभी-कभी जीवित वस्तुओं के बगल में लेट जाएंगे और कचरा संग्रह को प्रभावित करने के लिए संघर्ष करेंगे
• 1000 से अधिक तत्वों की लंबाई के साथ दोहरे सरणियों के उपयोग को नियंत्रित करें।

जहां उचित और संभव हो, थ्रेड स्टैक का उपयोग करें

समस्या

एक विधि कॉल (आंतरिक कॉल सहित) के भीतर रहने वाले कई अल्ट्राशॉर्ट ऑब्जेक्ट या ऑब्जेक्ट हैं। वे वस्तु यातायात बनाते हैं

निर्णय

• स्टैक पर मेमोरी आवंटन का उपयोग करना जहां संभव हो:
  
  • यह एक गुच्छा लोड नहीं करता है
  • जीसी लोड नहीं करता है
  • मेमोरी जारी करना - तुरंत
• Span T x = stackalloc T[]; उपयोग करें Span T x = stackalloc T[]; new T[] बजाय जहां संभव हो
• जहाँ संभव हो, Span/Memory उपयोग करें
• ref stack प्रकारों के लिए एल्गोरिदम में कनवर्ट करें (StackList: स्ट्रक्चर, ValueStringBuilder )

जितनी जल्दी हो सके मुक्त वस्तुओं

समस्या

अल्पकालिक के रूप में कल्पना की गई, वस्तुएं जीन 1 में और कभी-कभी जीन 2 में आती हैं।
यह एक भारी जीसी में परिणाम है जो लंबे समय तक रहता है

निर्णय

• आपको ऑब्जेक्ट संदर्भ को यथाशीघ्र जारी करना होगा
• यदि एक लंबी एल्गोरिथ्म में कोड होता है जो किसी भी ऑब्जेक्ट के साथ काम करता है, तो यह कोड द्वारा दिया जाता है। लेकिन जिसे एक स्थान पर समूहित किया जा सकता है, उसे समूहबद्ध करना आवश्यक है, जिससे उन्हें पहले एकत्र किया जा सके।
  
  • उदाहरण के लिए, लाइन 10 पर, संग्रह को निकाल लिया गया था, और लाइन 120 पर, इसे फ़िल्टर किया गया था।

GC.Collect () को कॉल करने की आवश्यकता नहीं है

समस्या

अक्सर ऐसा लगता है कि यदि आप GC.Collect () कहते हैं, तो यह स्थिति को ठीक कर देगा

निर्णय

• यह जीसी ऑपरेशन एल्गोरिदम सीखने के लिए बहुत अधिक सही है, ईटीडब्ल्यू और अन्य डायग्नोस्टिक टूल (जेटब्रेन्स डॉटमेरी, ...) के तहत आवेदन को देखें।
• सबसे समस्याग्रस्त क्षेत्रों का अनुकूलन करें

पिनिंग से बचें

समस्या

पिनिंग में कई समस्याएं हैं:

• कचरा संग्रहण की शिकायत करता है
• मुक्त मेमोरी स्पेस बनाता है (नोड्स फ्री-लिस्ट आइटम, ईंटों की मेज, बाल्टी)
• कार्ड टेबल से लिंक बनाते समय युवा पीढ़ी में कुछ वस्तुओं को छोड़ सकते हैं

निर्णय

यदि कोई अन्य रास्ता नहीं है, तो निश्चित () {} का उपयोग करें। कमिट का यह तरीका वास्तविक कमिट नहीं करता है: यह केवल तब होता है जब जीसी ने घुंघराले ब्रेस के अंदर काम किया हो।

अंतिम रूप देने से बचें

समस्या

अंतिम रूप से नियत नहीं कहा जाता है:

• बिन बुलाए वस्तु () वस्तु से सभी आउटगोइंग लिंक के साथ अंतिम रूप देने में परिणाम
• आश्रित वस्तुओं को योजना की तुलना में लंबे समय तक देरी हो रही है
• बुढ़ापा, पुरानी पीढ़ियों की ओर बढ़ रहा है
• यदि उसी समय उनके पास छोटे लोगों के लिंक होते हैं, तो वे कार्ड टेबल से लिंक उत्पन्न करते हैं
• पुरानी पीढ़ियों की असेंबली की शिकायत करना, उन्हें टुकड़े टुकड़े करना और स्वीप के बजाय कॉम्पैक्ट करना

निर्णय

धीरे से कॉल डिस्पोज़ ()

बहुत सारे धागे से बचें

समस्या

बड़ी संख्या में थ्रेड्स के साथ, आवंटन संदर्भ बढ़ता है, जैसा कि उन्हें प्रत्येक धागे को आवंटित किया जाता है:

• नतीजतन, GC.Collect तेजी से आता है।
• पंचांग खंड में जगह की कमी के कारण, संग्रह सामूहिक स्वीप का पालन करेगा

निर्णय

• कोर की संख्या से थ्रेड्स की संख्या को नियंत्रित करें

विभिन्न आकारों की वस्तुओं के यातायात से बचें

समस्या

जब विभिन्न आकारों और जीवनकाल की वस्तुओं को ट्रैफ़िक किया जाता है, तो विखंडन होता है:

• विखंडन अनुपात बढ़ाएँ
• सभी संदर्भ ऑब्जेक्ट्स में पता परिवर्तन चरण के साथ संग्रह ट्रिगर

निर्णय

यदि वस्तुओं का आवागमन माना जाता है:

• अतिरिक्त क्षेत्रों की उपस्थिति के लिए जांचें, आकार का अनुमान लगाते हुए
• स्ट्रिंग हेरफेर की कमी के लिए जाँच करें: जहां संभव हो, ReadOnlySpan / ReadOnlyMemory से बदलें
• जितनी जल्दी हो सके लिंक जारी करें
• खींचने का लाभ उठाएं
• कॉम्पैक्ट वस्तुओं के लिए डबल जीसी के साथ गर्म कैश और पूल। इस प्रकार, आप कार्ड तालिका के साथ समस्याओं से बचते हैं।