अत्यधिक भरी हुई .NET सेवा में कचरा संग्रहण का अनुकूलन

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



आधुनिक प्रोग्रामिंग भाषाओं को दो समूहों में विभाजित किया जा सकता है। C / C ++ या Rust जैसी भाषाओं में, मैन्युअल मेमोरी मैनेजमेंट का उपयोग किया जाता है, इसलिए प्रोग्रामर अधिक समय कोड लिखने, वस्तुओं के जीवनकाल को प्रबंधित करने और फिर डिबगिंग में बिताते हैं। इसी समय, मेमोरी के अनुचित उपयोग के कारण बग को डिबग करना सबसे कठिन है, इसलिए अधिकांश आधुनिक विकास स्वचालित मेमोरी प्रबंधन वाली भाषाओं में आयोजित किए जाते हैं। इनमें शामिल हैं, उदाहरण के लिए, जावा, सी #, पायथन, रूबी, गो, पीएचपी, जावास्क्रिप्ट, आदि। प्रोग्रामर विकास के समय को बचाते हैं, लेकिन आपको अतिरिक्त निष्पादन समय के लिए भुगतान करना होगा जो कार्यक्रम नियमित रूप से कचरा संग्रह पर खर्च करता है - उन वस्तुओं द्वारा कब्जा की गई मेमोरी को मुक्त करता है जिसमें कार्यक्रम में कोई लिंक नहीं बचा है। छोटे कार्यक्रमों में, यह समय नगण्य है, लेकिन जैसे-जैसे वस्तुओं की संख्या बढ़ती है और उनके निर्माण की तीव्रता बढ़ती है, कचरा संग्रह कार्यक्रम के कुल निष्पादन समय पर ध्यान देने योग्य योगदान करने लगता है।

पाइरस वेब सर्वर .NET प्लेटफॉर्म पर चलते हैं, जो स्वचालित मेमोरी प्रबंधन का उपयोग करता है। अधिकांश कचरा संग्रह 'दुनिया को रोकें' हैं, अर्थात अपने काम के समय, वे आवेदन के सभी थ्रेड्स को रोकते हैं। गैर-अवरुद्ध (पृष्ठभूमि) विधानसभाएं वास्तव में सभी थ्रेड्स को रोकती हैं, लेकिन बहुत कम समय के लिए। थ्रेड ब्लॉकिंग के दौरान, सर्वर अनुरोधों को संसाधित नहीं करता है, मौजूदा अनुरोधों को फ्रीज करता है, नए लोगों को कतार में जोड़ा जाता है। परिणामस्वरूप, कचरा संग्रह के समय संसाधित किए गए अनुरोधों को सीधे धीमा कर दिया जाता है, और संचित कतारों के कारण कचरा संग्रह पूरा होने के तुरंत बाद अनुरोधों को अधिक धीरे-धीरे संसाधित किया जाता है। इससे मीट्रिक "धीमे प्रश्नों का प्रतिशत" बिगड़ जाता है।

हाल ही में प्रकाशित पुस्तक कोनराड कोकोसा: प्रो .NET मेमोरी मैनेजमेंट (हम 2 दिनों में रूस में इसकी पहली प्रति कैसे लाए, इसके बारे में आप एक अलग पोस्ट लिख सकते हैं) के साथ सशस्त्र, पूरी तरह से .NET में मेमोरी प्रबंधन के विषय के लिए समर्पित, हमने समस्या का अध्ययन करना शुरू किया।

माप

पाइरस वेब सर्वर को प्रोफाइल करने के लिए, हमने प्रोफाइल व्यू यूटिलिटी ( https://github.com/Microsoft/perfview ) का उपयोग किया, जो .NET अनुप्रयोगों के लिए तेज किया गया। उपयोगिता विंडोज (ईटीडब्ल्यू) इंजन के लिए ईवेंट ट्रेसिंग पर आधारित है और प्रोफाइल अनुप्रयोग के प्रदर्शन पर कम से कम प्रभाव पड़ता है, जो इसे एक मुकाबला सर्वर पर उपयोग करने की अनुमति देता है। इसके अलावा, प्रदर्शन पर प्रभाव इस बात पर निर्भर करता है कि हम किस प्रकार की घटनाओं और किस जानकारी को एकत्र करते हैं। हम कुछ भी एकत्र नहीं करते हैं - आवेदन हमेशा की तरह काम करता है। इसके अलावा, PerfView को या तो पुनर्संयोजन या एप्लिकेशन को पुनरारंभ करने की आवश्यकता नहीं है।

/ GCCollectOnly पैरामीटर (ट्रेस समय 1.5 घंटे) के साथ PerfView ट्रेस चलाएं। इस मोड में, यह केवल कचरा संग्रहण कार्यक्रम एकत्र करता है और प्रदर्शन पर न्यूनतम प्रभाव डालता है। आइए मेमोरी ग्रुप / GCStats ट्रेस रिपोर्ट देखें, और इसमें कचरा संग्रहकर्ता घटनाओं का सारांश:



यहाँ हम कई दिलचस्प संकेतक एक साथ देखते हैं:

• दूसरी पीढ़ी में औसत बिल्ड पॉज़ समय 700 मिलीसेकंड है, और अधिकतम ठहराव लगभग एक सेकंड है। यह आंकड़ा उस समय को दिखाता है जिस पर .NET अनुप्रयोग स्टॉप में सभी थ्रेड्स, विशेष रूप से, यह पॉज़ सभी संसाधित अनुरोधों में जोड़ा जाएगा।
  
• दूसरी पीढ़ी की विधानसभाओं की संख्या 1 पीढ़ी के बराबर है और यह 0 वीं पीढ़ी की विधानसभाओं की संख्या से थोड़ी कम है।
  
• प्रेरित कॉलम दूसरी पीढ़ी में 53 विधानसभाओं को सूचीबद्ध करता है। प्रेरित विधानसभा GC.Collect () के लिए एक स्पष्ट कॉल का परिणाम है। हमारे कोड में, हमें इस पद्धति का एक भी कॉल नहीं मिला, जिसका अर्थ है कि हमारे एप्लिकेशन द्वारा उपयोग किए जाने वाले कुछ पुस्तकालयों को दोष देना है।
  

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

हमारी रुचि का डेटा GCStats रिपोर्ट में किसी अन्य तालिका से निकाला जा सकता है:



यहां कुछ मामले हैं जहां एक एप्लिकेशन एक बड़ी वस्तु बनाने की कोशिश करता है (.NET फ्रेमवर्क ऑब्जेक्ट्स में> 85,000 बाइट्स आकार में LOH - बड़े ऑब्जेक्ट हीप में बनाए जाते हैं), और इसे 2 डी असेंबली असेंबली के पूरा होने का इंतजार करना पड़ता है, जो पृष्ठभूमि में समानांतर में होता है। आबंटक के ये ठहराव उतने महत्वपूर्ण नहीं हैं, जितने कि कूड़े के ढेर के कारण, क्योंकि ये केवल एक धागे को प्रभावित करते हैं। इससे पहले, हमने .NET फ्रेमवर्क 4.6.1 के संस्करण का उपयोग किया था, और संस्करण 4.7.1 में Microsoft ने कचरा संग्रहकर्ता को अंतिम रूप दिया, अब यह आपको दूसरी पीढ़ी की पृष्ठभूमि के निर्माण के दौरान लार्ज ऑब्जेक्ट हीप में मेमोरी आवंटित करने की अनुमति देता है: https://docs.microsoft.com / आरयू-आरयू / डॉटनेट / फ्रेमवर्क / व्हाट्स-न्यू / # सामान्य-भाषा-रनटाइम-क्लर
इसलिए, हम उस समय के नवीनतम संस्करण 4.7.2 में उन्नत हुए।

दूसरी पीढ़ी का निर्माण

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



इसका मतलब यह है कि ध्यान देने योग्य मेमोरी लीक नहीं हैं, अर्थात्, बड़ी संख्या में दूसरी पीढ़ी की असेंबली एक और कारण से होती हैं। अगली परिकल्पना यह है कि मेमोरी ट्रैफ़िक बहुत अधिक है, यानी, कई ऑब्जेक्ट्स दूसरी पीढ़ी में आते हैं, और कई लोग वहां मर जाते हैं। ऐसी वस्तुओं को खोजने के लिए PerfView में एक / GCOnly मोड है। ट्रेस रिपोर्ट से, आइए 'जनरल 2 ऑब्जेक्ट डेथ्स (मोटे नमूने) स्टैक्स' पर ध्यान दें, जिसमें उन वस्तुओं का चयन होता है जो दूसरी पीढ़ी में मरते हैं, साथ ही उन स्थानों के कॉल स्टैक के साथ जहां ये ऑब्जेक्ट बनाए गए थे। यहाँ हम निम्नलिखित परिणाम देखते हैं:



लाइन खोलने के बाद, अंदर हमें कोड में उन स्थानों का कॉल स्टैक दिखाई देता है जो 2 जनरेशन तक रहने वाले ऑब्जेक्ट बनाते हैं। उनमें से हैं:

• System.Byte [] अगर आप अंदर देखें, तो हम देखेंगे कि JSON में क्रमांकन के लिए आधे से अधिक बफ़र हैं:
  

• स्लॉट [System.Int32] [] (यह हैशसेट कार्यान्वयन का हिस्सा है), System.Int32 [], आदि। यह हमारा कोड है जो क्लाइंट कैश की गणना करता है - उन निर्देशिकाओं, रूपों, सूचियों, मित्रों, इत्यादि को, जिन्हें यह उपयोगकर्ता देखता है और जो उसके ब्राउज़र या मोबाइल एप्लिकेशन में कैश्ड हैं:
  

दिलचस्प है, JSON के लिए और क्लाइंट कैश की गणना के लिए बफ़र सभी अस्थायी ऑब्जेक्ट हैं जो एक ही अनुरोध पर रहते हैं। वे दूसरी पीढ़ी तक क्यों रहते हैं? ध्यान दें कि ये सभी ऑब्जेक्ट एक बड़े आकार के सरणियाँ हैं। और आकार> 85000 बाइट्स पर, उनके लिए मेमोरी लार्ज ऑब्जेक्ट हीप में आवंटित की जाती है, जो केवल 2 वीं पीढ़ी के साथ मिलकर एकत्र की जाती है।

जांच करने के लिए, परफ़ॉर्मेंस / GCOnly परिणामों में 'GC Heap Alloc Ignore Free (मोटे नमूने) स्टैक' अनुभाग खोलें। वहां हम लार्जऑब्जेक्ट लाइन देखते हैं, जिसमें परफ्यूव्यू बड़ी वस्तुओं के निर्माण को समूह बनाता है, और अंदर हम सभी समान सरणियों को देखते हैं जो हमने पिछले विश्लेषण में देखा था। हम कचरा कलेक्टर के साथ समस्याओं के मूल कारण को स्वीकार करते हैं: हम कई अस्थायी बड़ी वस्तुओं का निर्माण करते हैं।

पाइरस प्रणाली में परिवर्तन

माप के परिणामों के आधार पर, हमने आगे के काम के मुख्य क्षेत्रों की पहचान की: जेन्सन में क्लाइंट कैश और क्रमांकन की गणना करते समय बड़ी वस्तुओं के खिलाफ लड़ाई। इस समस्या के कई समाधान हैं:

• सबसे बड़ी बात बड़ी वस्तुओं का निर्माण नहीं करना है। उदाहरण के लिए, यदि बड़े बफर बी का उपयोग अनुक्रमिक डेटा परिवर्तनों ए-> बी-> सी में किया जाता है, तो कभी-कभी इन परिवर्तनों को ए-> सी में बदलकर जोड़ा जा सकता है और ऑब्जेक्ट बी के निर्माण को समाप्त कर सकता है। यह विकल्प हमेशा लागू नहीं होता है, लेकिन यह सबसे सरल और सबसे प्रभावी।
  
• वस्तुओं का पूल। लगातार नई वस्तुओं को बनाने और उन्हें फेंकने के बजाय, कचरा कलेक्टर को लोड करके, हम मुफ्त वस्तुओं का संग्रह स्टोर कर सकते हैं। सबसे सरल मामले में, जब हमें एक नई वस्तु की आवश्यकता होती है, तो हम इसे पूल से लेते हैं, या पूल खाली होने पर एक नया निर्माण करते हैं। जब हमें ऑब्जेक्ट की आवश्यकता नहीं होती है, तो हम इसे पूल में वापस कर देते हैं। एक अच्छा उदाहरण .NET कोर में ArrayPool है, जो कि .NET फ्रेमवर्क में System.Buffers Nugger पैकेज के भाग के रूप में भी उपलब्ध है।
  
• बड़े के बजाय छोटी वस्तुओं का उपयोग करें।
  

बड़ी वस्तुओं के दोनों मामलों पर अलग से विचार करें - क्लाइंट कैश की गणना करना और JSON में क्रमबद्ध करना।

ग्राहक कैश गणना

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

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

आइए हम बड़ी वस्तुओं के निर्माण से छुटकारा पाने के लिए प्रस्तावित विकल्पों का विश्लेषण करें:

• बड़ी वस्तुओं का पूर्ण निपटान। यह दृष्टिकोण लागू नहीं होता है, क्योंकि डेटा तैयारी एल्गोरिदम अन्य चीजों के साथ, सेट की छंटाई और संघ के बीच उपयोग करते हैं, और उन्हें अस्थायी बफ़र्स की आवश्यकता होती है।
  
• वस्तुओं का एक पूल का उपयोग करना। इस दृष्टिकोण में कठिनाइयाँ हैं:
  
  • उपयोग किए गए संग्रह की विविधता और उनमें तत्वों के प्रकार: हैशसेट, सूची और सरणी का उपयोग किया जाता है (बाद के 2 को संयुक्त किया जा सकता है)। Int32, Int64, साथ ही सभी प्रकार की डेटा कक्षाएं संग्रह में संग्रहीत की जाती हैं। उपयोग किए जाने वाले प्रत्येक प्रकार के लिए, आपको अपने स्वयं के पूल की आवश्यकता होगी, जो विभिन्न आकारों के संग्रह को भी संग्रहीत करेगा।
    
  • संग्रह का कठिन जीवन समय। पूल से लाभ प्राप्त करने के लिए, इसमें मौजूद वस्तुओं को उपयोग के बाद वापस करना होगा। यह तब किया जा सकता है जब ऑब्जेक्ट का उपयोग एक विधि में किया जाता है। लेकिन हमारे मामले में स्थिति अधिक जटिल है, क्योंकि कई बड़ी वस्तुएं तरीकों के बीच यात्रा करती हैं, उन्हें डेटा संरचनाओं में डाल दिया जाता है, अन्य संरचनाओं में स्थानांतरित किया जाता है, आदि।
    
  • बोध। Microsoft से ArrayPool है, लेकिन हमें अभी भी सूची और HashSet की आवश्यकता है। हमें कोई उपयुक्त पुस्तकालय नहीं मिला, इसलिए हमें कक्षाओं को स्वयं लागू करना होगा।
• छोटी वस्तुओं का उपयोग। एक बड़े सरणी को कई छोटे टुकड़ों में विभाजित किया जा सकता है, जिसे मैं बड़े ऑब्जेक्ट हीप को लोड नहीं करूंगा, लेकिन 0 वीं पीढ़ी में बनाया जाएगा, और फिर 1 और 2 में मानक पथ के साथ जाना होगा। हमें उम्मीद है कि वे 2 वें तक नहीं रहेंगे, लेकिन कचरा संग्रहकर्ता द्वारा 0 वें स्थान पर एकत्र किया जाएगा, या 1 पीढ़ी में चरम मामलों में। इस दृष्टिकोण का लाभ यह है कि मौजूदा कोड में परिवर्तन न्यूनतम हैं। कठिनाई:
  
  • बोध। हमें कोई उपयुक्त पुस्तकालय नहीं मिला, इसलिए हमें स्वयं कक्षाएं लिखनी होंगी। पुस्तकालयों की कमी समझ में आती है, क्योंकि परिदृश्य "संग्रह जो बड़े ऑब्जेक्ट हीप को लोड नहीं करता है" एक बहुत ही संकीर्ण गुंजाइश है।

हमने 3 रास्तों पर जाने का फैसला किया और अपनी बाइक का आविष्कार लिस्ट और हैशसेट लिखने के लिए किया, न कि लार्ज ऑब्जेक्ट हीप को लोड करने के लिए।

टुकड़ा सूची

हमारा ChunkedList <T> IList <T> सहित मानक इंटरफेस को लागू करता है, जिसे मौजूदा कोड में न्यूनतम परिवर्तन की आवश्यकता होती है। हां, और न्यूटनसॉफ्ट.जॉन लाइब्रेरी का उपयोग हम स्वचालित रूप से इसे क्रमबद्ध करने में सक्षम हैं, क्योंकि यह IEnumerable <T> को लागू करता है:

public sealed class ChunkedList<T> : IList<T>, ICollection<T>, IEnumerable<T>, IEnumerable, IList, ICollection, IReadOnlyList<T>, IReadOnlyCollection<T> { 

मानक सूची <T> में निम्नलिखित फ़ील्ड हैं: तत्वों के लिए सरणी और भरे हुए तत्वों की संख्या। ChunkedList में <T> तत्वों के सरणियों की एक सरणी है, पूरी तरह से भरे हुए सरणियों की संख्या, अंतिम सरणी में तत्वों की संख्या। 85,000 से कम बाइट वाले तत्वों की प्रत्येक सारणी:

 private T[][] chunks; private int currentChunk; private int currentChunkSize; 

चूंकि ChunkedList <T> बल्कि जटिल है, हमने इस पर विस्तृत परीक्षण लिखे। किसी भी ऑपरेशन का कम से कम 2 मोड में परीक्षण किया जाना चाहिए: "छोटी" में जब पूरी सूची एक टुकड़े में 85,000 बाइट्स तक फिट होती है, और "बड़ी" जब इसमें एक से अधिक टुकड़े होते हैं। इसके अलावा, उन तरीकों के लिए जो आकार बदलते हैं (उदाहरण के लिए, जोड़ें), परिदृश्य और भी बड़े हैं: "छोटा" -> "छोटा", "छोटा" -> "बड़ा", "बड़ा" -> "बड़ा", "बड़ा" -> " छोटा है। " यहां काफी भ्रमित करने वाले सीमा मामले हैं जो इकाई परीक्षण अच्छी तरह से करते हैं।

स्थिति को इस तथ्य से सरल किया जाता है कि IList इंटरफ़ेस के कुछ तरीकों का उपयोग नहीं किया जाता है, और उन्हें छोड़ा जा सकता है (जैसे कि डालें, निकालें)। उनका कार्यान्वयन और परीक्षण काफी हद तक होगा। इसके अलावा, यूनिट परीक्षण लिखना इस तथ्य से सरल है कि हमें नई कार्यक्षमता के साथ आने की आवश्यकता नहीं है, ChunkedList <T> को सूची <T> के समान व्यवहार करना चाहिए। यही है, सभी परीक्षण निम्नानुसार आयोजित किए जाते हैं: एक सूची बनाएं <T> और ChunkedList <T>, उन पर समान संचालन करें और परिणामों की तुलना करें।

हमने यह सुनिश्चित करने के लिए बेंचमार्कडॉटनेट लाइब्रेरी का उपयोग करके प्रदर्शन को मापा कि सूची <T> से ChunkedList <T> पर स्विच करते समय हमने अपने कोड को बहुत धीमा नहीं किया। आइए, उदाहरण के लिए, सूची में आइटम जोड़ते हुए परीक्षण करें:

 [Benchmark] public ChunkedList<int> ChunkedList() { var list = new ChunkedList<int>(); for (int i = 0; i < N; i++) list.Add(i); return list; } 

और तुलना के लिए सूची <T> का उपयोग करके एक ही परीक्षण। 500 तत्व जोड़ने पर परिणाम (सब कुछ एक सरणी में फिट बैठता है):

50,000 तत्वों को जोड़ने पर परिणाम (कई सरणियों में विभाजित):


यदि आप 'औसत' कॉलम को देखते हैं, जो औसत परीक्षण निष्पादन समय प्रदर्शित करता है, तो आप देख सकते हैं कि हमारा कार्यान्वयन मानक से केवल 2-2.5 गुना धीमा है। यह मानते हुए कि वास्तविक कोड में, सूचियों के साथ किए गए ऑपरेशन केवल सभी कार्यों का एक छोटा सा हिस्सा हैं, यह अंतर नगण्य हो जाता है। लेकिन कॉलम 'Gen 2 / 1k op' (1000 टेस्ट रन के लिए दूसरी पीढ़ी की विधानसभाओं की संख्या) से पता चलता है कि हमने लक्ष्य प्राप्त कर लिया है: बड़ी संख्या में तत्वों के साथ, ChunkedList दूसरी पीढ़ी में कचरा पैदा नहीं करता है, जो हमारा काम है।

टुकड़ा सेट

इसी तरह, ChunkedHashSet <T> ISet <T> इंटरफ़ेस लागू करता है। ChunkedHashSet <T> लिखते समय, हमने ChunkedList में पहले से लागू किए गए छोटे चंक लॉजिक का फिर से उपयोग किया। ऐसा करने के लिए, हमने MIT लाइसेंस के तहत उपलब्ध .NET संदर्भ स्रोत से HashSet <T> का तैयार कार्यान्वयन लिया और इसमें ChunkedLists के साथ सरणियों को प्रतिस्थापित किया।

इकाई परीक्षणों में, हम सूचियों के लिए भी उसी चाल का उपयोग करते हैं: हम ChunkedHashSet के व्यवहार की तुलना <T> के संदर्भ HashSet <T> से करेंगे।

अंत में, प्रदर्शन परीक्षण। हमारे द्वारा उपयोग किया जाने वाला मुख्य ऑपरेशन सेट का संघ है, यही कारण है कि हम इसका परीक्षण कर रहे हैं:

 public ChunkedHashSet<int> ChunkedHashSet(int[][] source) { var set = new ChunkedHashSet<int>(); foreach (var arr in source) set.UnionWith(arr); return set; } 

और मानक हैशसेट के लिए सटीक एक ही परीक्षण। छोटे सेट के लिए पहला परीक्षण:

 var source = new int[][] { Enumerable.Range(0, 300).ToArray(), Enumerable.Range(100, 600).ToArray(), Enumerable.Range(300, 1000).ToArray(), } 

बड़े सेटों के लिए दूसरा परीक्षण जिसमें बड़ी वस्तुओं के एक समूह के साथ समस्या हुई:

 var source = new int[][] { Enumerable.Range(0, 30000).ToArray(), Enumerable.Range(10000, 60000).ToArray(), Enumerable.Range(30000, 100000).ToArray(), } 

परिणाम लिस्टिंग के समान हैं। ChunkedHashSet 2-2.5 गुना तक धीमा है, लेकिन एक ही समय में बड़े सेट पर यह 2 पीढ़ी के 2 आदेशों को कम परिमाण में लोड करता है।

JSON में सीरियललाइज़ेशन

पाइरस वेब सर्वर कई एपीआई प्रदान करता है जो विभिन्न क्रमांकन का उपयोग करता है। हमने बॉट्स द्वारा उपयोग की जाने वाली एपीआई और सिंक्रोनाइज़ेशन यूटिलिटी में बड़ी वस्तुओं के निर्माण की खोज की (बाद में पब्लिक एपीआई के रूप में संदर्भित)। ध्यान दें कि मूल रूप से एपीआई अपने स्वयं के क्रमांकन का उपयोग करता है, जो इस समस्या से प्रभावित नहीं है। हमने इस लेख के बारे में https://habr.com/en/post/227595/ , अनुभाग 2 में लिखा है। आपको पता नहीं है कि आपके आवेदन की अड़चन कहां है। " यही है, मुख्य एपीआई पहले से ही अच्छी तरह से काम कर रहा है, और समस्या सार्वजनिक एपीआई में अनुरोधों की संख्या और प्रतिक्रियाओं में डेटा की मात्रा बढ़ने के रूप में दिखाई दी।

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

करीब से निरीक्षण करने पर, हमें पता चला कि प्रतिक्रिया को क्रमबद्ध करने की प्रक्रिया में, हम मध्यवर्ती परिणाम के लिए एक अस्थायी बफर बनाते हैं ('सामग्री' UTF-8 एन्कोडिंग में JSON युक्त बाइट्स की एक सरणी है):

 var serializer = Newtonsoft.Json.JsonSerializer.Create(...); byte[] content; var sw = new StreamWriter(new MemoryStream(), new UTF8Encoding(false)); using (var writer = new Newtonsoft.Json.JsonTextWriter(sw)) { serializer.Serialize(writer, result); writer.Flush(); content = ms.ToArray(); } 

आइए देखें कि सामग्री का उपयोग कहां किया गया है। ऐतिहासिक कारणों से, सार्वजनिक एपीआई डब्ल्यूसीएफ पर आधारित है, जिसके लिए एक्सएमएल मानक अनुरोध और प्रतिक्रिया प्रारूप है। हमारे मामले में, XML प्रतिक्रिया में एक एकल 'बाइनरी' तत्व है, जिसके अंदर बेस 64 में JSON एन्कोड किया गया है:

 public class RawBodyWriter : BodyWriter { private readonly byte[] _content; public RawBodyWriter(byte[] content) : base(true) { _content = content; } protected override void OnWriteBodyContents(XmlDictionaryWriter writer) { writer.WriteStartElement("Binary"); writer.WriteBase64(_content, 0, _content.Length); writer.WriteEndElement(); } } 

ध्यान दें कि यहां एक अस्थायी बफर की आवश्यकता नहीं है। JSON को XmlWriter बफर को तुरंत लिखा जा सकता है जो WCF हमें प्रदान करता है, इसे उड़ने पर बेस 64 में एन्कोडिंग करता है। इस प्रकार, हम स्मृति आवंटन से छुटकारा पाने के लिए पहला रास्ता तय करेंगे:

 protected override void OnWriteBodyContents(XmlDictionaryWriter writer) { var serializer = Newtonsoft.Json.JsonSerializer.Create(...); writer.WriteStartElement("Binary"); Stream stream = new Base64Writer(writer); Var sw = new StreamWriter(stream, new UTF8Encoding(false)); using (var jsonWriter = new Newtonsoft.Json.JsonTextWriter(sw)) { serializer.Serialize(jsonWriter, _result); jsonWriter.Flush(); } writer.WriteEndElement(); } 

यहाँ Base64Writer XmlWriter पर एक सरल आवरण है, जो स्ट्रीम इंटरफ़ेस को लागू करता है, जो Base64 के रूप में XmlWriter को लिखता है। एक ही समय में, पूरे इंटरफ़ेस से, यह केवल एक लिखने की विधि को लागू करने के लिए पर्याप्त है, जिसे स्ट्रीमविटर में कहा जाता है:

 public class Base64Writer : Stream { private readonly XmlWriter _writer; public Base64Writer(XmlWriter writer) { _writer = writer; } public override void Write(byte[] buffer, int offset, int count) { _writer.WriteBase64(buffer, offset, count); } <...> } 

प्रेरित जी.सी.

आइए रहस्यमय प्रेरित कचरा संग्रह से निपटने की कोशिश करें। हमने GC.Collect कॉल के लिए हमारे कोड को 10 बार रीचेक किया, लेकिन यह विफल रहा। मैं इन घटनाओं को PerfView में पकड़ने में कामयाब रहा, लेकिन कॉल स्टैक बहुत सूचक नहीं है (DotNETRuntime / GC / ट्रिगर घटना):



एक छोटा सा सुराग है - प्रेरित कचरा संग्रह से पहले RecycleLimitMonitor.RaiseRecycleLimitEvent को कॉल करना। आइए कॉल के ढेर को RaiseRecycleLimitEvent विधि से देखें:

 RecycleLimitMonitor.RaiseRecycleLimitEvent(...) RecycleLimitMonitor.RecycleLimitMonitorSingleton.AlertProxyMonitors(...) RecycleLimitMonitor.RecycleLimitMonitorSingleton.CollectInfrequently(...) RecycleLimitMonitor.RecycleLimitMonitorSingleton.PBytesMonitorThread(...) 

विधियों के नाम उनके कार्यों के अनुरूप हैं:

• RecycleLimitMonitor.RecycleLimitMonitorSingleton के कंस्ट्रक्टर में, एक टाइमर बनाया जाता है जो एक निश्चित अंतराल पर PBytesMonitorThread को कॉल करता है।
  
• PBytesMonitorTread मेमोरी के उपयोग पर आँकड़े एकत्र करता है और, कुछ शर्तों के तहत, कलेक्ट इनक्वायरेक्टली कॉल करता है।
  
• CollectInfrequently AlertProxyMonitors को कॉल करता है, परिणामस्वरूप एक बूल मिलता है, और GC.Collect () कॉल करता है अगर यह सच हो जाता है। वह अंतिम कॉल के बाद से कचरा संग्रहकर्ता को दिए गए समय की निगरानी करता है, और अक्सर इसे कॉल नहीं करता है।
  
• AlertProxyMonitors, IIS वेब अनुप्रयोगों को चलाने की सूची के माध्यम से जाता है, प्रत्येक के लिए इसी RecycleLimitMonitor ऑब्जेक्ट को उठाता है, और RaiseRecycleLimitEvent को कॉल करता है।
  
• RaiseRecycleLimitEvent IObserver <RecycleLimitInfo> सूची उठाती है। हैंडलर एक पैरामीटर RecycleLimitInfo के रूप में प्राप्त करते हैं, जिसमें वे RequestGC ध्वज को सेट कर सकते हैं, जो संग्रह में वापस आता है, जिससे एक प्रेरित कचरा संग्रह होता है।
  

आगे की जांच से पता चलता है कि IObserver <RecycleLimitInfo> हैंडलर को RecycleLimitMonitor.Subscribe () विधि में जोड़ा जाता है, जिसे AspNetMemoryMonitor.Subscribe () विधि में कहा जाता है। इसके अलावा, डिफ़ॉल्ट IObserver <RecycleLimitInfo> हैंडलर (RecycleLimitObserver वर्ग) को AspNetMemoryMonitor वर्ग में लटका दिया गया है, जो ASP.NET कैश को साफ करता है और कभी-कभी कचरा संग्रह के लिए पूछता है।

प्रेरित जीसी की पहेली लगभग हल हो गई है। यह कचरा संग्रह क्यों कहा जाता है, इस सवाल का पता लगाना बाकी है। RecycleLimitMonitor IIS मेमोरी के उपयोग की निगरानी करता है (अधिक सटीक रूप से, निजी बाइट्स की संख्या), और जब इसका उपयोग एक निश्चित सीमा तक पहुंचता है, तो यह RaiseRecycleLimitEvent घटना को बढ़ाने के लिए एक बल्कि भ्रामक एल्गोरिथ्म द्वारा शुरू होता है। AspNetMemoryMonitor.ProcessPStreetBytesLimit का मान मेमोरी सीमा के रूप में उपयोग किया जाता है, और बदले में इसमें निम्न तर्क होते हैं:

• यदि IIS में एप्लिकेशन पूल को 'निजी मेमोरी लिमिट (KB)' पर सेट किया जाता है, तो किलोबाइट में मान वहाँ से लिया जाता है
  
• अन्यथा, 64-बिट सिस्टम के लिए, 60% भौतिक मेमोरी ली जाती है (32-बिट सिस्टम के लिए, तर्क अधिक जटिल है)।
  

जांच का निष्कर्ष यह है: ASP.NET अपनी मेमोरी सीमा के पास है और नियमित रूप से कचरा संग्रह को कॉल करना शुरू करता है। 'प्राइवेट मेमोरी लिमिट (KB)' सेट नहीं किया गया था, इसलिए ASP.NET 60% भौतिक मेमोरी तक सीमित था। समस्या को इस तथ्य से मुखौटा किया गया था कि टास्क मैनेजर सर्वर पर यह बहुत सारी मुफ्त मेमोरी दिखाता था और ऐसा लगता था कि यह गायब था। हमने IIS में एप्लिकेशन पूल सेटिंग्स में 'प्राइवेट मेमोरी लिमिट (KB)' मूल्य को भौतिक मेमोरी के 80% तक बढ़ा दिया है। यह ASP.NET को अधिक उपलब्ध मेमोरी का उपयोग करने के लिए प्रोत्साहित करता है। हमने प्रदर्शन काउंटर '.NET CLR मेमोरी / # प्रेरित GC' के मॉनिटरिंग को भी जोड़ा ताकि अगली बार ASP.NET को याद न किया जाए ताकि यह निर्णय लिया जा सके कि यह मेमोरी उपयोग सीमा के निकट है।

बार-बार माप

आइए देखें कि इन सभी परिवर्तनों के बाद कचरा संग्रह के साथ क्या हुआ। चलो perfview / GCCollectOnly (ट्रेस समय - 1 घंटे) के साथ शुरू करते हैं, GCStats रिपोर्ट:



यह देखा जा सकता है कि दूसरी पीढ़ी की विधानसभाएं अब 0 और 1 की तुलना में छोटे परिमाण के 2 ऑर्डर हैं। साथ ही, इन विधानसभाओं का समय भी घट गया। प्रेरित विधानसभाएं अब नहीं देखी जाती हैं। आइए दूसरी पीढ़ी की विधानसभाओं की सूची देखें:



जनरल कॉलम से पता चलता है कि दूसरी पीढ़ी की सभी असेंबली पृष्ठभूमि बन गई हैं ('2 बी' का अर्थ है 2 वीं पीढ़ी, पृष्ठभूमि)। यही है, अधिकांश कार्य आवेदन के निष्पादन के साथ समानांतर में किया जाता है, और सभी थ्रेड्स थोड़े समय के लिए अवरुद्ध हो जाते हैं (कॉलम 'पॉज़ एमएसके')। आइए बड़ी वस्तुओं को बनाते समय रुकें:



यह देखा जा सकता है कि बड़ी वस्तुओं को बनाते समय इस तरह के ठहराव की संख्या में काफी गिरावट आई।

परिणाम

लेख में वर्णित परिवर्तनों के लिए धन्यवाद, दूसरी पीढ़ी की विधानसभाओं की संख्या और अवधि को काफी कम करना संभव था। मैं प्रेरित विधानसभाओं का कारण खोजने और उनसे छुटकारा पाने में कामयाब रहा। 0 और पहली पीढ़ी की विधानसभाओं की संख्या में वृद्धि हुई, लेकिन उनकी औसत अवधि कम हो गई (~ 200 एमएस से ~ 60 एमएस तक)। 0 और 1 पीढ़ी की अधिकतम विधानसभा अवधि कम हो गई है, लेकिन ऐसा नहीं है। दूसरी पीढ़ी की असेंबलियाँ तेज़ हो गईं, 1000 किलोमीटर तक के लंबे ठहराव पूरी तरह से चले गए।

प्रमुख मीट्रिक के रूप में - "धीमी क्वेरी का प्रतिशत", यह सभी परिवर्तनों के बाद 40% तक कम हो गया।

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