Aspnetcore: एएसपीनेट कोर कचरा एकत्र नहीं कर रहा है

@rynowak

हालाँकि मैं कुछ नज़रअंदाज़ कर रहा हूँ ... मेरी समझ के लिए, इस पद्धति के लिए हर कॉल के साथ मेमोरी का उपयोग नहीं बढ़ना चाहिए। ऑब्जेक्ट बनने और UI को भेजे जाने के बाद, मेमोरी को मुक्त कर दिया जाना चाहिए था।

बड़ी वस्तु का ढेर आपको यहाँ काट रहा है। यदि आप ऑब्जेक्ट्स> 85KB आकार में आवंटित करते हैं तो इसे LOH में डाल दिया जाएगा और बहुत कम ही संकुचित हो जाएगा। देखें http://stackoverflow.com/questions/8951836/why-large-object-heap-and-why-do-we-care अधिक जानकारी के लिए (या https://github.com/dotnet/coreclr/blob/master /Documentation/botr/garbage-Collection.md#design-of-allocator अगर आप गहराई में जाना चाहते हैं)।

मुझे समझ में नहीं आता क्यों Asp.net कोर कचरा इकट्ठा नहीं कर रहा है। पिछले सप्ताह मैंने एक वेब सेवा को कुछ दिनों के लिए चलने दिया, और मेरी मेमोरी का उपयोग 20GB तक पहुंच गया

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

Enumerable.Repeat . को कॉल करने के बजाय शुरुआत से ही सरणी आवंटित करने का प्रयास करें
या GCSettings.LargeObjectHeapCompactionMode (.Net Standard में समर्थित) का उपयोग करके मेमोरी को संकुचित करें।

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

@zorthgo यकीन है कि यह डैपर नहीं है? यदि आप PHP की तरह सीधे अपनी SQL स्क्रिप्ट में पैरामीटर इंजेक्ट करके अपनी स्क्रिप्ट बनाते हैं तो आप बहुत सारी कैश्ड SQL स्क्रिप्ट के साथ समाप्त हो जाएंगे। यहां बताया गया है कि डैपर यह कैसे करता है
https://github.com/StackExchange/Dapper/blob/fe5c270aceab362c936456087a830e6fe1603cac/Dapper/SqlMapper.cs
आवंटित स्मृति के संदर्भों को रखने के बारे में बताने के लिए आपको मेमोरी प्रोफाइलर का उपयोग करना चाहिए। विजुअल स्टूडियो 2017 आपके ऐप पर कई कॉल से पहले और बाद में मेमोरी से कुछ स्नैपशॉट लेने और उनकी तुलना करने में आपकी सहायता करने में सक्षम होना चाहिए।

@zorthgo हाँ मैंने यह भी देखा है। मेरे .net कोर कंसोल ऐप में सर्विसस्टैक का उपयोग कर रहा था और हर बार जब मैं एपीआई को कॉल करता हूं तो मेमोरी उपयोग में भारी मात्रा में 50 एमबी की वृद्धि होती है। मैंने मान लिया कि यह VS2017 बग था लेकिन फिर टास्क मैनेजर में उच्च उपयोग की पुष्टि की। जैसा कि ज़ोर्थगो ने एपीआई को सरल कॉल करके कहा है, स्मृति उपयोग में काफी वृद्धि हुई है और ऐसा लगता है कि स्मृति जारी नहीं होती है।

क्या यह केवल ASP.NET Core पर .NET Core पर होता है या यह .NET Framework पर ASP.NET Core के साथ भी एक समस्या है?

क्या आप MVC 5 (System.Web पर) का उपयोग करके एक समान एप्लिकेशन लिख सकते हैं और सत्यापित कर सकते हैं कि आपको वही व्यवहार दिखाई नहीं दे रहा है?

मैं इस मुद्दे से इसकी वर्तमान स्थिति में कोई प्रगति नहीं कर सकता।

मेरे उदाहरण में मैं केवल लक्ष्य ढांचे का उपयोग कर रहा था। NetCoreApp 1.1 और मेरा कंसोल ऐप एक साझा प्रोजेक्ट में ऑब्जेक्ट मॉडल का संदर्भ दे रहा था।

सुनिश्चित नहीं है कि यह किसी की मदद करेगा। एक नमूना ऐप जो hellorequest को कॉल करता है। इस ऐप में स्टार्टअप मेमोरी 85mb है, फिर दोहराए जाने वाले अनुरोध से मैं मेमोरी उपयोग को लगभग 145mb तक बढ़ाने में कामयाब रहा। यह कभी-कभी 125mb तक गिर जाता है लेकिन फिर वहीं रहता है। सुनिश्चित नहीं है कि यह सामान्य व्यवहार है क्योंकि मुझे नेट कोर कंसोल ऐप्स के लिए उपयोग नहीं किया जाता है। मैंने हमेशा माना कि मैं कुछ गलत कर रहा था या सही ढंग से तत्काल नहीं कर रहा था।

https://drive.google.com/open?id=0B0Gm-m-z_U84TU5keWFTMzc1ZWc

3000-5000 सक्रिय उपयोगकर्ताओं के साथ उत्पादन के लिए तैनात एक Asp.Net कोर एप्लिकेशन पर यहां एक ही समस्या का सामना करना पड़ रहा है.. सर्वर पर मेमोरी कल बढ़कर 15GB हो गई ... मामला क्या है यह जानने की कोशिश करें।

क्या किसी ने मेमोरी डंप लिया और देखा कि आपके विशेष एप्लिकेशन में सभी मेमोरी क्या ले रही है?

@davidfowl @Pinox
मैं एक बड़ी कंपनी में काम कर रहा हूं, और हम ASP.NET Core के साथ एक नया प्रोजेक्ट शुरू करना चाहते हैं, लेकिन जब मैंने इस मुद्दे को देखा, तो मैं डर गया: चिंतित:। यह एक महत्वपूर्ण मुद्दा है और हमारी परियोजना के जीवनचक्र को अवरुद्ध कर सकता है।

तो कृपया, क्या यह ASP.NET Core या .NET Core (CoreCLR) से संबंधित है? हम Full .NET (4.6) को लक्षित करेंगे इसलिए मैं पूछ रहा हूँ।

@ikourfaln मेरे मामले में मैं .net कोर कंसोल ऐप, सर्विसस्टैक (.net कोर संस्करण) और केस्ट्रेल का उपयोग कर रहा था। अजीब बात यह है कि मेमोरी का उपयोग एक स्तर तक बढ़ जाता है, फिर यह अचानक बंद हो जाता है और फिर से ऊपर नहीं जाता है। मुझे लगता है कि छोटे नमूने और व्यवहार की जांच के साथ इसे अपने पक्ष में जांचना सबसे अच्छा है।

शायद @zorthgo अपनी तरफ से जांच कर सकता है कि क्या वह देखता है कि उस स्मृति में एक निश्चित स्तर पर समान व्यवहार का उपयोग किया जाता है और फिर बढ़ना बंद हो जाता है क्योंकि यही वह व्यवहार है जिसे मैं देख रहा हूं। मैंने @zorthgo उदाहरण को शामिल करने के लिए अपना नमूना ऐप अपडेट किया है और मुझे स्मृति दूर नहीं दिख रही है। यह ऊपर जाता है लेकिन अंत में रुक जाता है।

मैंने स्रोत को थोड़ा बदल दिया:

सार्वजनिक वस्तु कोई भी (टेस्टजीसी अनुरोध)
{
कॉन्स्ट स्ट्रिंग संदेश = "टेस्ट";
गणना करने योग्य वापसी। दोहराएं (संदेश, 100000);
}

@पिनॉक्स
धन्यवाद, मैं अपनी तरफ से व्यवहार की जांच करूंगा।

2.0 में इस बग के बारे में कैसे?

इसकी कोई खबर? मैं नेट फ्रेमवर्क पर कोर 2 का उपयोग कर रहा हूं और यह अभी भी हो रहा है। _Controller_ को प्रत्येक कॉल से उपयोग की गई मेमोरी बढ़ जाती है, लेकिन यह कभी कम नहीं होती है। (_मैंने वेबएपी टेम्पलेट का उपयोग किया_)

नमस्ते,

मेरे पास ASP.NET Core 2 के साथ एक ही समस्या है। मैंने मेमोरी डंप लिया है और विश्लेषण करने का प्रयास किया है। मैं जो देखता हूं उससे समस्या ठीक वैसी ही है जैसी ओपी ने कहा था। मेरा आवेदन लगभग 75 एमबी आवंटन के साथ शुरू होता है, और बहुत जल्दी यह ~ 750 एमबी तक चला जाता है, इसमें से 608 एमबी ".NET को आवंटित अप्रयुक्त स्मृति" है।

ऐप शुरू होने पर पहला स्नैपशॉट:

3 मिनट और 100 अनुरोधों के बाद दूसरा स्नैपशॉट:

हम भी एक ही समस्या का सामना कर रहे हैं, हमारा नियंत्रक बड़ी मात्रा में डेटा से निपट रहा है, (जो खराब डिज़ाइन है और जल्द ही बदल दिया जाएगा), इस नियंत्रक को प्रत्येक कॉल स्मृति को बढ़ने का कारण बन रही है। मेमोरी कम हो जाती है लेकिन केवल 40-50% (50 एमबी हासिल करें, 30-35 एमबी कम करें), प्रत्येक कॉल हर बार 10-15 एमबी की सीमा में मेमोरी बढ़ाती है। सर्विस को सर्विस फैब्रिक के अंदर होस्ट किया जाता है।

ऐसा लगता है कि हमारी उत्पादन सेवा (20-100 req/s) में एक संयोजन का उपयोग करके मेरे पास एक समान समस्या है:

• ASP.NET कोर 2.0.4
• सर्विसस्टैक.कोर 1.0.44
• स्कीयाशार्प 1.59.2
• डॉकर v17.09.0-ce, Ubuntu 16.04 x64 पर afdb6d4 का निर्माण करें
• x4 सर्वर @ 40 सीपीयू, 128 जीबी मेमोरी
• सर्वर जीसी सच है
• प्रत्येक डॉकर कंटेनर 12k (mhz) CPU शेयरों, 8GB ram . पर सेट है

एप्लिकेशन में एक फ्रंट-एंड वेब सर्वर और वर्कर है (क्रमशः नीचे दिए गए ग्राफ़ में दिखाया गया है)।

वेब सर्वर (पिछले 6 घंटे)

कार्यकर्ता (पिछले 6 घंटे)

वे दोनों बड़े बाइट सरणियों का उपयोग करते हैं क्योंकि सेवा एक वस्तु भंडारण प्रॉक्सी के रूप में कार्य कर रही है, और परिणामस्वरूप वस्तुओं को LOH में रखती है। मेरा प्रश्न है, क्या यह इस समय .NET कोर की एक ज्ञात सीमा है? ऐसा लगता है जैसे LOH कभी पूरी तरह से साफ या खंडित नहीं हुआ।

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

@sebastienros - इस पर कोई विचार? क्या हमने अपने सिस्टम में कोई समान व्यवहार देखा है?

• हम इसे केवल 2.1 पर मापते हैं, मैं 2.0 . के लिए एक ही चीज़ जोड़ने पर विचार करूंगा
• सभी टिप्पणियां एलओएच मुद्दे से संबंधित प्रतीत होती हैं जिसका उल्लेख किया गया था, जिसे आवेदन में ध्यान में रखा जाना चाहिए और जितना संभव हो सके बड़े सरणी पूल करना चाहिए

@sebastienros , कई प्रश्न:

1. मैंने मेमोरी उपयोग को मापने के लिए एंट्स प्रोफाइलर का उपयोग किया, इसके अनुसार, कोई LOH विखंडन नहीं पाया गया। क्या आप सलाह दे सकते हैं कि मैं कैसे सत्यापित कर सकता हूं कि मेरा आवेदन एलओएच विखंडन मुद्दों से ग्रस्त है या नहीं?
2. .NET कोर 2.1 पर परिणाम क्या हैं? क्या समस्या हल हो गई है क्योंकि Kestrel स्पैन का उपयोग कर रहा है?
3. क्या होगा यदि हम सरणियों को पूल नहीं कर सकते - क्या आप एक समाधान प्रदान कर सकते हैं? क्या हमें GCSettings.LargeObjectHeapCompactionMode.CompactOnce का उपयोग करना चाहिए?

.NET कोर 2.1 पर परिणाम क्या हैं? क्या समस्या हल हो गई है क्योंकि Kestrel स्पैन का उपयोग कर रहा है?

हमने व्यक्तिगत रूप से कोई सबूत नहीं देखा है कि समस्या Kestrel में है। यह अभी भी एक आवेदन समस्या की तरह दिखता है।

क्या होगा यदि हम सरणियों को पूल नहीं कर सकते - क्या आप एक समाधान प्रदान कर सकते हैं? क्या हमें GCSettings.LargeObjectHeapCompactionMode.CompactOnce का उपयोग करना चाहिए?

@jkotas @Maoni0 यहाँ कोई सलाह?

अगर मैं एक ही समस्या से पीड़ित हूं तो मैं कैसे जांच कर सकता हूं? रेडगेट मेमोरी प्रोफाइलर के अनुसार LOH लगभग खाली है जैसा कि @sinapis वर्णन करता है, लेकिन फिर भी केवल एक उपयोगकर्ता के लिए 1GB से अधिक आसान का उपयोग कर रहा है

ट्रेस एकत्र करें और परफव्यू का उपयोग करके इसका विश्लेषण करें। .NET मेमोरी लीक का पता लगाने के तरीके पर वेंस और अन्य द्वारा कई ट्यूटोरियल हैं: https://www.bing.com/search?q=.NET%20memory%20leak%20perfview ।

https://github.com/dotnet/coreclr/blob/master/Documentation/project-docs/linux-performance-tracing.md में निशान एकत्र करने के लिए लिनक्स विशिष्ट निर्देश हैं।

यदि आप मानते हैं कि कोई स्मृति रिसाव नहीं है और जीसी केवल आपके आस-पास अधिक स्मृति रख रहा है, तो आप कोशिश कर सकते हैं:

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

नमस्ते,

मुझे लगता है कि उत्पादन में नेट कोर वेब एपीआई के साथ मुझे एक ही तरह की समस्या हो रही है।

एप्लिकेशन विंडोज सर्वर 2016 पर .Net Core 2.0.3 के साथ चल रहा है। मशीन एक हाइपर-वी वीएम है जिसमें 28 सीपीयू कोर और 24 जीबी रैम है। यदि हम आईआईएस एप्लिकेशन पूल को अक्सर पर्याप्त रूप से रीसायकल नहीं करते हैं, तो हम अंततः सभी उपलब्ध मेमोरी का उपयोग करेंगे। जब एप्लिकेशन बहुत अधिक मेमोरी (>=कुल सिस्टम मेमोरी का 95%) का उपयोग करना शुरू कर देता है, तो CPU उपयोग भी दृढ़ता से बढ़ जाता है (कभी-कभी 2% से 70% तक)। मुझे यकीन नहीं है कि ओओएम अपवाद ट्रिगर किया गया है या नहीं, हम हमेशा पूल को रीसायकल करने से पहले ऐसा करते हैं (अधिकतम मेमोरी उपयोग मैंने देखा है कि डॉटनेट.एक्सई द्वारा उपयोग की जाने वाली मेमोरी का 98% था)।

".नेट मेमोरी पोर्फ़िलर" (साइटेक सॉफ्टवेयर) के साथ उत्पादन मेमोरी डंप का विश्लेषण यहां मैंने पाया है:

यदि यह विश्लेषण सही है, तो लगभग 95% मेमोरी "ओवरहेड> अप्रयुक्त" में है। यहां बताया गया है कि यह मेमोरी प्रोफाइलर संपादक इस श्रेणी (उनके मंच पर) का वर्णन कैसे कर रहा है:
_"ओवरहेड->अप्रयुक्त" प्रबंधित हीप के लिए .NET रनटाइम द्वारा प्रतिबद्ध मेमोरी है। यह वर्तमान में अप्रयुक्त है, लेकिन यह भविष्य के उदाहरण आवंटन के लिए उपलब्ध है। कई नियम हैं जो रनटाइम यह तय करने के लिए उपयोग करता है कि प्रतिबद्ध मेमोरी को रखना है या इसे ओएस पर जारी करना है। यह उपलब्ध मेमोरी, आवंटन पैटर्न, प्रोसेसर की संख्या, सर्वर जीसी का उपयोग किया जाता है, आदि जैसे कारकों पर निर्भर करता है।_

@jkotas मैं आपकी सिफारिशों को लागू करूंगा (विंडोज जॉब ऑब्जेक्ट, और वर्कस्टेशन जीसी पर स्विच करना) और मैं आपको परिणाम बता दूंगा। कृपया मुझे बताएं कि क्या मैं अपने पास मौजूद उत्पादन मेमोरी डंप से कोई अन्य उपयोगी जानकारी निकाल सकता हूं।

धन्यवाद

@sinapis @ronald7
क्या आप में से कोई एक ऐसा ऐप साझा कर पाएगा जो समस्या दिखाता है? अगर मैं इसे पुन: पेश कर सकता हूं तो हम इसका कारण ढूंढ पाएंगे, या कम से कम कुछ कोड टुकड़े टुकड़े करके हटा देंगे और न्यूनतम रेप्रो को अलग कर देंगे।

@sebastienros मैं ऐप साझा नहीं कर सकता, लेकिन मैं सत्र को PerfView सत्र + मेमोरी डंप से साझा कर सकता हूं।
कुछ विवरण: मेरे पास ASP.NET Core 2 वेब API है, मैंने 200 उपयोगकर्ताओं का लोड परीक्षण बनाया है जो सभी 10 सेकंड में एक ही अनुरोध भेज रहे हैं। कुल मिलाकर 775 अनुरोधों पर कार्रवाई की गई।

यह ऐप टास्क मैनेजर में लगभग 1 जीबी मेमोरी उपयोग के लिए कूद गया और उसी तरह बना रहा। डंप को देखते हुए मैं लगभग 18 एमबी गिन सकता हूं:

तो सवाल यह है कि लगभग 1 जीबी कहां गया?

@sinapis धन्यवाद

आप जिस व्यवहार का वर्णन कर रहे हैं वह अप्रत्याशित नहीं है, जीसी पीक लोड पर आवश्यकतानुसार कुछ मेमोरी आवंटित करेगा, और इसे समय के साथ जारी करेगा। यह जीसी सर्वर मोड है, और आमतौर पर इसे जारी करने के लिए निष्क्रिय अवधि की प्रतीक्षा करें और आपके ऐप को प्रभावित न करें। यह आरक्षित मेमोरी की मात्रा सिस्टम पर उपलब्ध कुल मेमोरी पर निर्भर करता है।

अगर यह बढ़ता रहा तो हम निश्चित रूप से एक मुद्दा देखेंगे। मुझे लगता है कि यदि आप अब और अनुरोध नहीं भेजते हैं और अपना ऐप चलाने देते हैं तो आप देखेंगे कि स्मृति उपयोग कम हो रहा है।

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

क्या आप नौकरियों के दौरान और अंत में डंप भी ले सकते हैं, ताकि हम विवरण देख सकें।

नमस्ते @sebastienros

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

मैंने एक प्रोडक्शन सर्वर पर GC मोड को _server_ से _workstation_ में अपडेट कर दिया है, अगर यह मेमोरी उपयोग पर कुछ भी बदलता है तो मैं आपको कुछ घंटों में बता दूंगा।

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

शुक्रिया

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

@ Maoni0 कृपया साझा करें कि मुझे GC लॉगिंग को कैसे सक्षम करना चाहिए
यदि कोई अन्य डेटा है जो आप चाहते हैं कि मैं लेखांकन त्रुटि को अस्वीकार करने के लिए प्रदान करूं तो कृपया मुझे बताएं कि मुझे आपको क्या प्रदान करना चाहिए और कैसे (शायद अधिक डेटा एकत्र करने के लिए परफव्यू बताएं?)
मैं एक न्यूनतम रेपो बनाने की कोशिश करूंगा, लेकिन मुझे यकीन नहीं है कि मैं सफल होऊंगा क्योंकि मुझे नहीं पता कि समस्या कहां है।

@sebastienros उम्मीद है कि मैं आज अधिक मेमोरी खपत के साथ एक और डंप प्रदान करूंगा

हाय @sebastienros @Maoni0 ,

मैंने अपना आवेदन वर्कस्टेशन जीसी मोड के साथ 12 घंटे तक चलाया लेकिन एक ही परिणाम। मैंने 1 घंटे के लिए एकल उत्पादन नोड पर .Net 2.1 पूर्वावलोकन 2 के साथ एप्लिकेशन को फिर से संकलित किया, मैं आपको परिणाम बता दूंगा, लेकिन अभी के लिए प्रक्रिया पहले से ही 2GB+ RAM का उपयोग कर रही है।

मेरे पास इसी मशीन पर PerfView चल रहा है और मैं GC डंप एकत्र कर रहा हूं, क्या कोई ईमेल पता है जहां मैं आपको OneDrive लिंक भेज सकता हूं, दुर्भाग्य से मैं इसे सीधे इस थ्रेड में साझा नहीं कर सकता।

अगर यह मदद कर सकता है तो मैं और मेट्रिक्स या जीसी लॉग भी एकत्र कर सकता हूं। शुक्रिया

@ronald7 _redacted_ मैं @ Maoni0 . को फॉरवर्ड कर सकता हूं

नमस्ते @sebastienros @Maoni0 मैंने अभी आपको दो PerfView gcdump और एक VMMap फ़ाइल के साथ एक ईमेल भेजा है, मुझे आशा है कि यह मदद कर सकता है। मेरी तरफ से मैं अभी भी इस उच्च स्मृति उपयोग व्यवहार को एक डमी एप्लिकेशन के साथ पुन: पेश करने का प्रयास कर रहा हूं।

धन्यवाद!

मैं भी इसी समस्या का सामना कर रहा हूं। कचरा संग्रहण कभी नहीं होता है! स्क्रीनशॉट एक साधारण डॉटनेट कोर वेब एपीआई ऐप का उपयोग करके लगभग 50 अनुरोध करने के बाद मेमोरी उपयोग दिखाता है।

मैंने अभी उबंटू 16.04 पर चल रहे ASP.NET कोर ऐप को 1.1 से 2.0 तक अपग्रेड किया और इस समस्या में भाग गया। यह बहुत गंभीर है, जिससे कर्नेल ओओएम त्रुटियों के कारण अक्सर ऐप को मार देता है, और मैं विचार कर रहा हूं कि 1.x पर वापस डाउनग्रेड करना है या नहीं। कुछ ऐसे पृष्ठ हैं जिन्हें हम बिल्कुल भी लोड नहीं कर सकते हैं - Kestrel पुनरारंभ होने के बाद भी, ऐप तुरंत एक अनुरोध के बाद उपलब्ध मेमोरी को समाप्त कर देता है! मैंने सर्वर को अपग्रेड करने के बारे में सोचा था, लेकिन सभी उपलब्ध मेमोरी का उपयोग करने वाले ASP.NET कोर ऐप्स के बारे में यहां टिप्पणियों के आधार पर, मुझे उम्मीद नहीं है कि इससे मदद मिलेगी। हमारा स्टैक मूल रूप से ASP.NET MVC Core + EF Core है ... कुछ भी फैंसी नहीं है। अगर मुझे कुछ समय मिलता है तो मैं इस मुद्दे को पुन: पेश करने के लिए एक नमूना बनाने की कोशिश करूंगा - मुझे नहीं लगता कि यह इतना कठिन होना चाहिए, हमारे ढेर की सादगी को देखते हुए।

FWIW, जिस सिस्टम को मैंने अपग्रेड किया है उसमें एक .NET कोर कंसोल ऐप भी है, और ऐसा लगता है कि 2.0 अपग्रेड के बाद कोई मेमोरी समस्या नहीं है, इसलिए यह निश्चित रूप से ASP.NET कोर-संबंधित समस्या प्रतीत होती है।

संभवतः संबंधित: https://github.com/aspnet/KestrelHttpServer/issues/2214

@danports क्या आपने GC.Collect() को कॉल करने का प्रयास किया है, देखें कि स्मृति उपयोग नाटकीय रूप से कम हो गया है या नहीं? यह हमें एक सुराग देगा कि हमें कहां से शुरू करना चाहिए। यदि GC.Collect() (या GC.Collect/GC.WaitingForPendingFinalizers/GC.Collect sequent) मेमोरी के उपयोग को नाटकीय रूप से कम करने में सक्षम नहीं है, तो इसका मतलब है कि बस इतनी मेमोरी है जिसे लाइव करने की आवश्यकता है इसलिए GC इसे पुनः प्राप्त नहीं कर सकता है।

@ Maoni0 मैंने अभी तक यह कोशिश नहीं की है। मुझे नहीं लगता कि मेरी समस्या जीसी के साथ है, क्योंकि मैंने समय-समय पर मेमोरी उपयोग में गिरावट देखी है - ऐसा लगता है कि मेरे .NET कोर 2.0 ऐप्स लगभग 2-3x मेमोरी की खपत करते हैं, जब वे चल रहे थे। नेट कोर 1.1। मैं

मैंने अभी के लिए .NET Core 1.1 पर वापस डाउनग्रेड किया है और बाद में जब मेरे पास अधिक समय होगा, शायद .NET Core 2.1 जारी होने के बाद इसे फिर से देखेंगे। (मैं 2.0 के साथ मुद्दों के ढेर में भाग गया और यह उनमें से सिर्फ एक था।)

GC.Collect() मदद नहीं करता है। एक बहुत ही सरल ASP.NET Core 2.0 और 2.1 वेब API का प्रयास किया जिसमें एक नियंत्रक है जो 200k ints का शब्दकोश देता है। आवंटित मेमोरी प्रत्येक अनुरोध के साथ बढ़ती रहती है, भले ही ऐप किसी और मेमोरी का उपयोग न करे।

@Serjster 200K पूर्णांक (4B) लौटाने में 800KB लगेगा। इस मामले में आप इस टिप्पणी में बताए गए मुद्दे को मार रहे हैं: https://github.com/aspnet/Home/issues/1976#issuecomment -289336916

इस मामले में आपको अनुरोधों में उनका पुन: उपयोग करने के लिए एक सरणी पूल का उपयोग करना चाहिए।

यह जानना भी अच्छा है कि यदि कोड 64 बिट मोड में चल रहा है तो सरणी/सूची इत्यादि जिसमें पॉइंटर्स होते हैं, 32 बिट की तुलना में दोगुने आकार के होते हैं। अगर मुझे सही ढंग से याद है कि पूर्ण ढांचा डिफ़ॉल्ट रूप से 64 बिट ओएस में किसी भी सीपीयू कोड 32 बिट को चलाता है। इसलिए अपने कोड को माइग्रेट करने वाले लोग गलती से LOH मुद्दों पर आ सकते हैं।

मैं @Serjster के साथ काम कर रहा हूं, और यहां मैंने जो पाया है। अगर मैं एएसपीनेट कोर (मैंने अपने नवीनतम परीक्षण में 2.1 का उपयोग किया) का उपयोग करके एक वेनिला वेब एपीआई प्रोजेक्ट बनाता हूं, तो मुझे लगता है कि जब मैं डायग्नोस्टिक टूल चलाता हूं (या कोड में सेट की गई प्रक्रिया मेमोरी की जांच भी करता हूं), बाइट्स की संख्या वापस आती है जैसे ही मैं एक समापन बिंदु से टकराता हूं, चढ़ता रहता है। उदाहरण के लिए, यदि मेरे पास एक एकल वेब एपीआई एंडपॉइंट है जो एक डिक्शनरी लौटा रहा हैइसमें 20,000 वस्तुओं के साथ, निम्नलिखित होता है:

1. नियंत्रक विधि की पहली यात्रा प्रोसेस मेमोरी को 83MB पर रखती है।
2. मैं कुछ सेकंड प्रतीक्षा करता हूं, और फिर दूसरी यात्रा यह 86MB तक बढ़ जाती है।
3. मैं कुछ सेकंड प्रतीक्षा करता हूं, और तीसरी यात्रा 90 एमबी तक बढ़ जाती है।
4. फिर से - 94 एमबी।
5. मैं इसे कई बार करता हूं, और अंत में यह लगभग 304MB तक पहुंच जाता है। एक बार ऐसा करने के बाद यह स्तर बंद हो जाता है।

यदि रिटर्न ऑब्जेक्ट एक अलग आकार की वस्तु है, तो उपरोक्त सभी संख्याएं केवल बड़ी/छोटी हैं (स्तर बंद राशि सहित), लेकिन विकास पैटर्न समान है (उर्फ, यह तब तक बढ़ेगा और बढ़ेगा जब तक कि यह कई अनुरोधों के बाद बंद न हो जाए) .

अगर मैं GC.Collect को मेथड कॉल में जोड़ता हूं (इसलिए यह हर एक अनुरोध पर होता है, का स्तर बहुत कम है, लेकिन अभी भी विकास की अवधि है जब तक कि यह बंद न हो जाए।

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

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

संपादित करें - फिर से @davidfowl टिप्पणी: शायद ही कभी एकत्र होने वाली चीजों के बारे में आपकी टिप्पणी के बारे में ... यह समझ में आ सकता है। लेकिन आम तौर पर इसमें कितना समय लगता है? मैं अनुरोधों के बीच 30+ सेकंड जा सकता हूं, और जीसी कभी भी उस मेमोरी नंबर को डायग्नोस्टिक चार्ट में वापस नहीं लाता है। मुझे यकीन है कि मैं यहाँ किसी चीज़ से अनजान हूँ, लेकिन बस जिज्ञासु हूँ।

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

संपादित करें 3 - एक लंबा प्रश्न। प्रक्रिया मेमोरी लगातार ऊपर क्यों जा रही है, लेकिन अगर यह एक LOH मुद्दा है तो ढेर का आकार नहीं बढ़ रहा है? दरअसल, अब मैं इसे समझ सकता हूं। ढेर प्रयुक्त स्मृति है। प्रोसेसर आवंटित मेमोरी उपयोग की गई मेमोरी और अप्रयुक्त मेमोरी ब्लॉक हैं।

@RemyArmstro क्या आप Dictionary<int, int> से SortedDictionary<int, int> में बदल सकते हैं? शब्दकोश शायद निरंतर स्मृति आवंटित कर रहा है, यहां तक ​​​​कि प्रत्येक प्रविष्टि में कुछ अतिरिक्त डेटा भी जोड़ सकता है। वे सॉर्टेड डिक्शनरी को लागू किया गया है, यह एक बड़े के बजाय कई छोटे आवंटन करेगा।

संपादित करें: यदि आप स्ट्रिंग को क्रमबद्ध करते हैं और सीधे आउटपुट स्ट्रीम पर प्रतिक्रिया नहीं देते हैं तो इससे LOH आवंटन भी हो सकता है।

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

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

मेरी इच्छा है कि Microsoft खंडित कार्यान्वयन बनाएगा जिसका उपयोग हर कोई इस तरह की स्थितियों में कर सकता है।

@ wanton7 फिर भी आप इस बिंदु को याद कर रहे हैं। यह सूची के आकार से कोई फर्क नहीं पड़ता। यहां तक ​​कि कोई एक वस्तु या छोटी सूची भी इस समस्या का कारण बनती है।

@Serjster शायद मैं सिर्फ अंधा हूं, लेकिन मुझे आपकी कोई पोस्ट नहीं दिख रही है जहां आपने कहा था कि एकल आइटम या छोटी सूची भेजने से ऐसा होगा। क्या आपने इसे हटा दिया?

या @RemyArmstro से वह विभिन्न आकार के शब्दकोशों के बारे में बात करता है। मैंने corefx की जाँच की और डिक्शनरी सरणी आवंटित करेगा या ये

private struct Entry
{
  public int hashCode;    // Lower 31 bits of hash code, -1 if unused
  public int next;        // Index of next entry, -1 if last
  public TKey key;           // Key of entry
  public TValue value;         // Value of entry
}

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

शब्दकोश कार्यान्वयन विवरण Dictionary.cs

संपादित करें: निश्चित यूआरएल

@ वांटन 7 धन्यवाद। मुझे लगता है कि अब हम समझ गए हैं कि मामला क्या है। यह सिर्फ एक बकवास है इसका कोई अच्छा + सरल समाधान नहीं है। यह मूल रूप से इसके बारे में अधिक जागरूक होने और कोड लिखने के तरीके को समायोजित करने के लिए नीचे आता है। नकारात्मक पक्ष यह है कि यह अप्रबंधित स्मृति कुछ अधिक प्रबंधित महसूस होने लगती है। :( अंत में, हमारे पास केवल कुछ क्षेत्र हो सकते हैं जो वास्तव में इस आवंटन सीमा का उल्लंघन करते हैं, लेकिन एक क्षेत्र हमारे ऐप के लिए बहुत महत्वपूर्ण है, इसलिए हम इसे वर्तमान में बहुत कुछ देखते हैं। मुझे लगता है कि हमें उस टुकड़े पर पुनर्विचार करने की आवश्यकता है, मॉनिटर करें, और किसी भी अन्य क्षेत्र को खोजने का प्रयास करें जहां हम इस रेंगना को देखते हैं। फिर से धन्यवाद!

हमारे पास वास्तव में जल्द ही ऐसी ही स्थिति है और हमें IList<T> कार्यान्वयन को खंडित करने की आवश्यकता है। मैं बिट्स के लिए कुछ आकार का उपयोग करने जा रहा हूं जो कि बिटशिफ्टेबल है इसलिए मैं इंडेक्सिंग के लिए बिटशिफ्ट और मास्क का उपयोग कर सकता हूं।

मैं जानना चाहता हूं कि जीसी के लिए कौन सा अधिक फायदेमंद है, बड़ा हिस्सा या छोटा हिस्सा? 1KB और 64KB के बीच के आकार से। छोटे हिस्से का मतलब जीसी के लिए अधिक संदर्भ है लेकिन मुझे लगता है कि कॉम्पैक्टिंग और विखंडन के लिए बड़ा हिस्सा खराब हो सकता है।

आपकी समझ बिल्कुल सही है - मैं उन आकारों के साथ जाऊंगा जो बहुत बड़े नहीं हैं; शायद 4k/8k का प्रयास करें।

@ Maoni0 धन्यवाद!

मैंने 4KB को चुना, ताकि अगर हम कभी मोनो के तहत अपना कोड चलाते हैं तो हमें कोई बुरा आश्चर्य नहीं होता है। http://www.mono-project.com/docs/advanced/garbage-collector/sgen/working-with-sgen/ पढ़कर पता चला कि मोनो के तहत LOH थ्रेशोल्ड केवल 8000 बाइट्स है।

क्या इस मुद्दे पर कोई प्रगति हुई है?

हम उसी मुद्दे को देख रहे हैं जहां ढेर आकार समान (या घटने) के बावजूद प्रक्रिया स्मृति बढ़ती जा रही है।

@sebastienros क्या आप इस पर एक और नज़र डाल सकते हैं? हो सकता है कि हम लोगों को उनके परिदृश्यों की और जाँच करने में मदद करने के लिए कुछ विस्तृत निर्देश प्रदान कर सकें?

हमारी स्थिति पर विचार करने के लिए यहां कुछ आइटम दिए गए हैं:

• हम केवल Dictionary<int, int> ऑब्जेक्ट लौटा रहे हैं जिसमें 1000 पूर्णांक मान संग्रहीत हैं। इससे ज्यादा कुछ नहीं।
• हमने अपने प्रोजेक्ट को .NET Core 2.0 -> 2.1 . से रूपांतरित किया है
• हम इस मुद्दे को एमएस विजुअल स्टूडियो 2017 में देख रहे हैं

कोड इस प्रकार है:

    public async Task<IActionResult> SampleAction()
    {
        var list = new Dictionary<int, int>();
        for (int n = 0; n < 1000; n++) list.Add(n, n);
        return Ok(list);
    }

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

मैं इसे अपनी परियोजनाओं में से एक में भी देख रहा हूं, लेकिन मैं इसे एक नए .net कोर एपीआई लक्ष्यीकरण में भी फिर से बना सकता हूं। नेट कोर 2.1 (एसडीके 2.1.302)।

मैंने विजुअल स्टूडियो 15.8.0 पूर्वावलोकन 4 का उपयोग करके बनाए गए नमूना एपीआई प्रोजेक्ट को संलग्न किया। स्मृति को बढ़ाने के लिए मेरे पास एक .net कोर कंसोल ऐप था जो डिफ़ॉल्ट मानों को हिट करता था 2 स्ट्रिंग प्राप्त करने के लिए हर आधे सेकेंड में एंडपॉइंट प्राप्त करें। प्रक्रिया मेमोरी का उपयोग धीमा है लेकिन एक प्रोजेक्ट में जो अधिक डेटा देता है, यह तेजी से बढ़ सकता है।

वेबएप्लीकेशन1.ज़िप

मुझे यह पोस्ट स्टैक एक्सचेंज पर मिली:

https://stackoverflow.com/questions/48301031/why-doesnt-garbage-collector-in-net-core-2-0-free-all-memory

क्या यह व्यवहार मौजूद है या नहीं यह देखने के लिए किसी ने अपने एप्लिकेशन को रिलीज मोड में प्रोफाइल किया है? मैं इसे आज एक शॉट दूंगा और देखूंगा कि क्या समस्या बनी रहती है।

संपादित करें : मैंने रिलीज मोड में प्रोफाइलिंग करने की कोशिश की और समस्या अभी भी बनी हुई है। मैं जीसी को यह देखने के लिए भी मजबूर करता हूं कि इसका कोई असर होगा या नहीं।

@chrisaliotta उस पोस्ट से जुड़ने के लिए धन्यवाद, मैं उस व्यवहार से अनजान था। यह देखना वाकई दिलचस्प होगा कि क्या यह बताता है कि लोग क्या देख रहे हैं।

@Eilon @chrisaliotta धन्यवाद लेकिन यह इस चर्चा से संबंधित नहीं है। .NET डिबग मोड में मेमोरी जारी नहीं करना एक प्रसिद्ध व्यवहार है और यही कारण है कि हम केवल रिलीज़ मोड में मेमोरी खपत (और संभावित लीक) को मापते हैं। रिलीज मोड पर भी आप देखेंगे कि सर्वर जीसी मोड के कारण मेमोरी एक हद तक ओवरटाइम तक बढ़ जाती है। तो यह उदाहरण दो अलग-अलग कारणों से कुछ भी साबित नहीं करता है।

@sebastienros तो क्या यह व्यवहार @beef3333 और मैं देख रहे हैं कि क्या अपेक्षित है? अर्थात्, जहां निजी बाइट्स ढेर के आकार में कमी के बावजूद ऊंचा रहता है? यदि ऐसा है, तो यह मेरे लिए अजीब लगता है कि प्रत्येक वृद्धिशील अनुरोध मुक्त ढेर स्थान होने के बावजूद निजी बाइट बढ़ने का कारण बनता रहेगा।

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

मैंने रिलीज मोड में संलग्न उसी प्रोजेक्ट का उपयोग करके इसे फिर से परीक्षण किया और मैं वही सटीक व्यवहार देख रहा हूं।

मैं तब आपके आवेदन का परीक्षण करूंगा, धन्यवाद।

मैंने स्थानीय रूप से @beef3333 द्वारा प्रदान किए गए एप्लिकेशन को 2 घंटे के लिए 5K RPS की दर से चलाया, और मेमोरी स्थिर है (32GB वाली मशीन पर 400MB पर कुल मिलाकर 1MB का अंतर)। जीसी को नियमित रूप से सही ढंग से बुलाया जाता है। मैंने कई डंप ओवरटाइम का भी निरीक्षण किया और उम्मीद के मुताबिक विभिन्न उदाहरण बनाए और एकत्र किए गए। मैं 2.1.1 का उपयोग कर रहा हूँ।

@sebastienros इसे देखने के लिए धन्यवाद। मुझे लगता है कि इस सब में मुख्य बात यह है कि:

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

अगर मैं गलत हूं तो मुझे सुधारें, लेकिन ऐसा प्रतीत होता है कि सबसे तेज प्रतिक्रिया समय सुनिश्चित करने के लिए .NET कोर औसत अनुरोधों के आधार पर आवंटित स्मृति को बढ़ाएगा? यदि सही है, तो क्या यह मान लेना सुरक्षित होगा कि यह इस आवंटित मेमोरी को तब तक जारी नहीं करेगा जब तक कि एप्लिकेशन पूल रीसेट नहीं हो जाता - या यदि RPS कम हो जाता है तो क्या यह समय के साथ इस आवंटित मेमोरी को रिलीज़ करेगा?

वही मुद्दा।
मेरे पास एएसपीनेट वेबपी बैकएंड सेवा है।
स्टैक एएसपीएनटी एमवीसी, ऑटोफैक, ऑटोमैपर, कैसल.डायनामिक प्रॉक्सी, इकाई फ्रेमवर्क कोर हैं।
सारी मेमोरी खा ली जाएगी, फिर सर्विस क्रैश।

संस्करण 2.1.0 . है

@atpyk 2.1.1 पर अपडेट करें। अगर इससे आपको मदद नहीं मिलती है तो आपको वास्तव में उस मेमोरी को रखने वाले प्रोफाइल को प्रोफाइल करना चाहिए। मैंने https://www.jetbrains.com/dotmemory/ का उपयोग किया है, लेकिन शायद ऐसे अन्य टूल भी हैं जो ऐसा कर सकते हैं। यह दिखा सकता है कि वास्तव में बड़े ऑब्जेक्ट हीप (LOH) में क्या आवंटित किया गया है।

क्या आप 32 बिट मोड में चल रहे हैं? क्योंकि बड़े ऑब्जेक्ट हीप आवंटन (~ 85000 बाइट्स से बड़ा) विखंडन के कारण 32 बिट मोड में मेमोरी अपवादों का कारण बन सकता है। आप Dictionary . का उपयोग करके इस सीमा को बहुत आसानी से पार कर सकते हैं. इस टिप्पणी की जाँच करें https://github.com/aspnet/Home/issues/1976#issuecomment -393833505

यदि आप अपना कोड पूर्ण रूप से चला रहे हैं। नेट फ्रेमवर्क डिफ़ॉल्ट व्यवहार 32 बिट मोड में कोई भी सीपीयू कोड चला रहा है। आपको प्रोजेक्ट सेटिंग्स से प्रेफर 32 बिट को अनचेक करना होगा या अपने सर्वर रजिस्ट्री में कुछ रजिस्ट्री सेटिंग को डिफ़ॉल्ट रूप से 64 बिट पर सेट करना होगा।

@ wanton7 बहुत धन्यवाद। मैं आपके समाधान का प्रयास करूंगा।

मैंने 2.1.2 में अपडेट किया और Microsoft Azure webapp पर win-x64 के साथ तैनात किया, लेकिन कोई प्रभाव नहीं पड़ा। @ वांटन7

@atpyk कृपया एक मेमोरी स्नैपशॉट बनाएं (डंप_ और इसका विश्लेषण करें (विजुअल स्टूडियो, मेमोस्कोप) यह देखने के लिए कि कौन सी वस्तु सभी मेमोरी ले रही है, या बस गिनती में बढ़ रही है। आप दो भी ले सकते हैं और उनकी तुलना ओवरटाइम कर सकते हैं।

@sabastienros मुझे विश्वास है कि पर्याप्त लोगों ने इस पर चिंता जताई है कि आपको/एमएस को वास्तव में इसका विश्लेषण करना शुरू करना चाहिए। शायद यह आपके इरादे से काम कर रहा है, लेकिन फिर डिज़ाइन त्रुटिपूर्ण है।

हमारे ऐप्स अंततः मेमोरी से बाहर हो रहे हैं और क्रैश हो रहे हैं, और यह सब एक उत्पादन Azure वातावरण में चल रहा है। यह स्वीकार्य नही है।

@atpyk तो यह एक स्मृति रिसाव की तरह लगता है। यह देखने के लिए अपनी मेमोरी को प्रोफाइल करें कि उस मेमोरी को आसपास क्या रख रहा है जैसे @sebastienros ने कहा।

एक सवाल, क्या आप भी ASP.NET Core का उपयोग कर रहे हैं? मैंने आपको पहली बार फिर से टिप्पणी पढ़ी और आप ASP.NET MVC का उल्लेख करते हैं। ASP.NET MVC और ASP.NET Core दो पूरी तरह से अलग उत्पाद हैं। ASP..NET Core के लिए ये मुद्दे और यह रेपो।

संपादित करें: बस संस्करण संख्या से लगता है जैसे आप ASP.NET कोर का उपयोग कर रहे हैं, लेकिन सुनिश्चित करना चाहते हैं।

हम नेट कोर एमवीसी का उपयोग करते हैं। @ वांटन7
मैं स्मृति का विश्लेषण कर रहा हूं। हो सकता है कि कैसल डायनेमिक प्रॉक्सी मेमोरी लीक की ओर ले जाए।

@Serjster क्या आपके प्रोग्राम 32 बिट .NET कोर में चल रहे हैं और मेमोरी अपवादों के साथ क्रैश हो रहे हैं? यदि आपका कोड बहुत सारे LOH आवंटन करता है तो स्मृति विखंडन शायद इसका कारण है।
यदि आप 32 बिट वातावरण में चल रहे हैं तो आपके पास दो विकल्प हैं, LOH से बचने के लिए अपना कोड ठीक करें या 64 बिट वातावरण में स्विच करें।

मैं Azure से बहुत परिचित नहीं हूं, लेकिन थोड़ी सी गुगली करने के बाद मुझे यह https://blogs.msdn.microsoft.com/webdev/2018/01/09/64-bit-asp-net-core-on-azure-app मिला

@Serjster मेरा मानना ​​​​है कि यहां सभी रिपोर्ट समान नहीं हैं, और प्रत्येक अलग मामले की वैधता की जांच करना पसंद करते हैं। "मेरे ऐप में मेमोरी लीक है" जैसा कुछ इसका मतलब यह नहीं है कि यह ढांचे की वजह से है, इसलिए मैं प्रत्येक मामले को वास्तविक सुनिश्चित करना पसंद करता हूं।

उदाहरण के लिए आपके मामले को लेते हुए, "मुझे विश्वास है" कि मैंने आपकी याददाश्त बढ़ने के कारण का उत्तर दिया। क्या आप मेरे स्पष्टीकरण के बाद इसे ठीक कर पाए हैं? या इसने इस मुद्दे को हल नहीं किया और इस मामले में क्या आप एक आवेदन दे सकते हैं जिसे मैं स्थानीय रूप से इस मुद्दे को पुन: उत्पन्न करने के लिए चला सकता हूं?

@sebastienros हमने जो पाया वह यह था कि स्मृति आवंटन में वृद्धि जारी रही, भले ही स्मृति खपत नहीं हुई। मुझे पता है कि ASP.NET कोर यह बताने के लिए कुछ अनुमान लगा रहा है कि इसे और अधिक हथियाना चाहिए, लेकिन ऐसा लग रहा था कि यह प्रत्येक अनुरोध पर लगातार अधिक से अधिक आवंटित कर रहा है। इस संबंध में यह मुझे लगभग लालची प्रतीत होता है, लेकिन मैं गलत हो सकता था।

किसी भी तरह से, मुझे लगता है @Serjster बिंदु यह है कि यह धागा बढ़ता रहता है क्योंकि यहां स्पष्ट रूप से कुछ भ्रम है। पुरानी ASP.NET भूमि में (कोर 1 से पहले मुझे विश्वास है), हमें इस व्यवहार को देखने की आवश्यकता नहीं थी (कम से कम इस परिमाण पर नहीं। यह वास्तव में बग/मुद्दा नहीं हो सकता है, लेकिन यह निश्चित रूप से बहुत से लोगों को पैदा कर रहा है एक ही सवाल को बार-बार करने के लिए।

यह अच्छा होगा यदि कोई आधिकारिक लेख था जो वास्तव में इस धागे को ऊपर से नीचे तक संबोधित करता है, बजाय इसके कि यह पहले से ही हलकों में जा रहा है। उम्मीद है कि यह स्पष्ट करने में मदद करता है।

यह अच्छा होगा यदि कोई आधिकारिक लेख था जो वास्तव में इस धागे को ऊपर से नीचे तक संबोधित करता है, बजाय इसके कि यह पहले से ही हलकों में जा रहा है। उम्मीद है कि यह स्पष्ट करने में मदद करता है।

मैं उसे समर्थन देता हूँ। हमारे लिए यह जानना अच्छा होगा कि जब स्मृति प्रबंधन की बात आती है तो .NET Core 2.1 पहले के संस्करणों की तुलना में अधिक "अवसरवादी" क्यों है।

@sebastienros क्या हम यहां मुद्दों का सारांश दे सकते हैं? 81 टिप्पणियाँ हैं - मुझे लगता है कि वे सभी मुद्दों के बारे में नहीं हैं (हालाँकि मैंने उन्हें ध्यान से नहीं पढ़ा है इसलिए मुझसे गलती हो सकती है)। यदि हां, तो क्या हम यहां सभी विशिष्ट मुद्दों को सूचीबद्ध कर सकते हैं और देख सकते हैं कि क्या हमारे पास उनमें से प्रत्येक के लिए रिप्रोज़ हैं? ऐसे पर्याप्त लोग हैं जिन्होंने स्मृति वृद्धि का उल्लेख किया है, मुझे लगता है कि यह हमें रेप्रो प्राप्त करने और यह पता लगाने के लिए उचित ठहराता है कि ये सामान्य मुद्दे हैं या नहीं।

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

समानांतर में मैं एक ऐसे दस्तावेज़ पर काम करूंगा जो सभी सिफारिशों, ज्ञात स्मृति मुद्दों (LOB, HttpClient, ...) और इन मुद्दों का विश्लेषण और रिपोर्ट करने के तरीकों को सूचीबद्ध करता है।

केवल आपको आश्वस्त करने के लिए कि हम इस मुद्दे की परवाह करते हैं और मेमोरी लीक का पता लगाने के लिए, पिछले 6 महीनों से हम 24 और 7 दिनों के लिए, लिनक्स और विंडोज दोनों पर, Azure पर लगातार ASP.NET एप्लिकेशन चला रहे हैं। ये परीक्षण प्रत्येक पुनरावृत्ति (दैनिक या साप्ताहिक) पर नवीनतम ASP.NET स्रोत प्राप्त करते हैं। हम आरपीएस, विलंबता, सीपीयू और मेमोरी उपयोग को मापते हैं। एप्लिकेशन ईएफ कोर, एमवीसी और रेजर का उपयोग करता है, और एक महत्वपूर्ण भार को अनुकरण करने के लिए 50% सीपीयू तक कायम रहता है।

आप इस साइट पर सार्वजनिक रूप से यहाँ परिणाम देख सकते हैं (दैनिक रिपोर्ट को खोजने के लिए ब्राउज़ करें): https://msit.powerbi.com/view?r=eyJrIjoiYTZjMTk3YjEtMzQ3Yi00NTI5LTg5ZDItNmUyMGRlOTkwMGRlIiwidCI6IjcyZjk4OGJmLTg2ZjEtNDFhZi05MWFiLTJkN2NkMDExZGI0NyIsImMiOjV9&pageName=ReportSectioneeff188c61c9c6e3a798

इसने हमें अतीत से कुछ समस्याओं को ठीक करने की अनुमति दी है, और यह सुनिश्चित करने के लिए कि अभी सिस्टम में कोई मौलिक रिसाव नहीं है। लेकिन यह हमारे द्वारा शिप किए जाने वाले सभी घटकों का उपयोग करने के करीब नहीं है, और ऐसे मुद्दे हो सकते हैं जिन्हें हमें पहचानने की आवश्यकता है। डंप और एप्लिकेशन प्रदान करना जो समस्याओं को पुन: उत्पन्न करते हैं, वे मुख्य तरीके हैं जिनसे आप हमारी मदद कर सकते हैं।

@sebastienros अपडेट के लिए धन्यवाद। मुझे पता है कि हमारे मामले में यह मुद्दा एक नई "लालची स्मृति आवंटन" चिंता के बारे में अधिक था, जिसे हमने मूल रूप से स्मृति रिसाव के रूप में गलत समझा था। मुझे यकीन भी नहीं है कि अब कोई समस्या है, यह हो सकता है कि नए अनुकूलन अनुमान बहुत अधिक आक्रामक हों। यकीन नहीं हो रहा है... लेकिन मुझे लगता है कि आप इस सूत्र का वास्तव में आकलन करने के साथ सही रास्ते पर हैं और लोग क्या देख रहे हैं/गलतफहमी पर कुछ समेकित स्पष्टीकरण/सारांश लेकर आ रहे हैं। आपको कामयाबी मिले!

सभी व्यक्तिगत रिपोर्टों को अलग-थलग कर दिया गया है और अलग-अलग फॉलो-अप प्राप्त होंगे, और यदि वे पहले से ही हल हो गए हैं तो उन्हें बंद कर दिया जाएगा। लूप में बने रहने के लिए इन्हें सब्सक्राइब करने के लिए स्वतंत्र महसूस करें।

समानांतर में मैं एक ऐसे दस्तावेज़ पर काम करूंगा जो सभी सिफारिशों, ज्ञात स्मृति मुद्दों (LOB, HttpClient, ...) और इन मुद्दों का विश्लेषण और रिपोर्ट करने के तरीकों को सूचीबद्ध करता है।

यह मेरी ओर से एक बहुत बड़ा +1 है। मुझे लगता है कि यहां सबसे बड़े मुद्दों में से एक यह है कि जानकारी इकट्ठा करना कितना मुश्किल लगता है, फिर कोशिश करें और यह निर्धारित करने में मदद करें कि समस्या क्या है। कुछ महान दस्तावेज़ होने से हम दोनों को कुछ निर्देशों का पालन करने की अनुमति दे सकते हैं (i) इकट्ठा, (ii) एक आत्म-निदान का प्रयास करें और (iii) हमारे डंप/निष्कर्षों को इस तरह से पोस्ट करें जो एमएस टीम के लिए कुशल हो, वास्तव में दोनों की मदद कर सकता है बाड़ के किनारे।

यदि हम (डेवलपर्स) निदान और/या जानकारी प्रदान करने के लिए बेहतर रूप से सक्षम हो सकते हैं, तो यह सभी के लिए एक जीत है।

@Sebastienros सुनने के लिए फिर से धन्यवाद - बहुत सराहना की, दोस्त!

आप नीचे दिए गए चित्र में स्थिति के बारे में क्या सोचते हैं?

हम एक ही प्लान के अंदर 4 WebApps चलाते हैं। प्रारंभ में यह बी 1 था, जिसे एस 2 तक बढ़ाया गया था और जब तक मैं भूखे वेबएप csproj पर सेट नहीं हो जाता, तब तक मेमोरी बढ़ती रही:

<ServerGarbageCollection>false</ServerGarbageCollection>

और एप्लिकेशन अंतर्दृष्टि को भी अक्षम करें

1. मेरा मानना ​​​​है कि चूंकि उपरोक्त सेटिंग के साथ स्मृति को नियंत्रण में रखा जा सकता है, इसलिए कोई स्मृति ली नहीं है। सही?
2. क्या प्रस्तुत व्यवहार सामान्य है?

यहाँ @alexiordan जैसी ही स्थिति है, हमारे पास एक .net कोर 2.1 कंसोल था, जो Kube में होस्ट किए गए कुछ IHostedServices को Microsoft/ dotnet:2.1-runtime AS बेस से चलाता था। हम HealthChecks को सक्षम करना चाहते थे इसलिए हमने केवल HealthChecks मिडलवेयर के साथ asp.net को जोड़ा और मूल छवि को Microsoft/ dotnet:2.1-aspnetcore-runtime में बदल दिया। परिणाम ओओएम था। हम जोड़कर स्मृति आवंटन को स्थिर करने में कामयाब रहे हैंअसत्य csproj में।

हमारे विश्लेषण से पता चला है कि एएसपीनेट ऐप में जीसी कम बार इकट्ठा होता है, साथ ही फ़ाइनलाइज़र क्यू को भी कम बार ट्रैवर्स किया जाता है।

इसके अलावा, अगर हमने जीसी को अपनी पाइपलाइन में निम्नलिखित जोड़कर अंतिम कतार को इकट्ठा करने और पार करने के लिए मजबूर किया,

सिस्टम.जीसी.कलेक्ट ();
System.GC.WaitForPendingFinalizers ();
सिस्टम.जीसी.कलेक्ट ();

स्मृति आवंटन स्थिर रहा।

आप नीचे दिए गए चित्र में स्थिति के बारे में क्या सोचते हैं?

हम एक ही प्लान के अंदर 4 WebApps चलाते हैं। प्रारंभ में यह बी 1 था, जिसे एस 2 तक बढ़ाया गया था और जब तक मैं भूखे वेबएप csproj पर सेट नहीं हो जाता, तब तक मेमोरी बढ़ती रही:

<ServerGarbageCollection>false</ServerGarbageCollection>

और एप्लिकेशन अंतर्दृष्टि को भी अक्षम करें

1. मेरा मानना ​​​​है कि चूंकि उपरोक्त सेटिंग के साथ स्मृति को नियंत्रण में रखा जा सकता है, इसलिए कोई स्मृति ली नहीं है। सही?
2. क्या प्रस्तुत व्यवहार सामान्य है?

अरे @alexiordan

एआई (नेट कोर 2.1 पर वेब ऐप) का उपयोग करते समय हम एक बहुत ही समान मेमोरी प्रोफाइल देख रहे हैं, क्या आपने इसे हल करने में और प्रगति की है? जाहिर है हम एआई को ऐप्स में रखना चाहते हैं।

यह अजीब है कि प्रत्येक अनुरोध पर उपयोग बढ़ता है, लेकिन उपरोक्त को गलत पर सेट करना मेरे लिए इसे रोकना प्रतीत होता है? अजीब है क्योंकि आपको लगता है कि सच वह मूल्य होगा जो इसे सक्षम बनाता है, लेकिन ऐसा लगता है कि यह दूसरी तरफ है ...

मैं यह उल्लेख करना भूल गया कि इस सूत्र में वर्णित मुद्दों के बारे में एक लेख लिखने के अपने इरादे की घोषणा करने के तुरंत बाद मैंने वास्तव में ऐसा किया। आप इसे यहाँ देख सकते हैं: https://github.com/sebastienros/memoryleak

यह एक छोटे से एप्लिकेशन के साथ आता है जो चार्ट पर पैटर्न को लाइव करता है।

लेकिन उपरोक्त को गलत पर सेट करना मेरे लिए इसे रोकना प्रतीत होता है? अजीब है क्योंकि आपको लगता है कि सच वह मूल्य होगा जो इसे सक्षम बनाता है, लेकिन ऐसा लगता है कि यह दूसरी तरफ है ...

क्लाइंट कचरा संग्रह (कई ऐप्स के साथ मेमोरी साझा करने और मेमोरी को मुक्त रखने के लिए अनुकूलित) सर्वर कचरा संग्रह (थ्रूपुट और समवर्ती के लिए अनुकूलित) की तुलना में अधिक आक्रामक है।

एसजीसी को गलत पर सेट करना, मेरी एएसपीनेट कोर एपीआई 150 एमबी से 48 एमबी तक गिर गई, और उसके बाद प्रत्येक अनुरोध पर नहीं बढ़ी। तो क्या वास्तव में यह अभी के लिए उत्पादन के लिए सबसे अच्छी सेटिंग है?

@kgrosvenor वास्तव में, यह निर्भर करता है। उत्कृष्ट @sebastienros लेख से उद्धरण:

एक विशिष्ट वेब सर्वर वातावरण पर सीपीयू संसाधन मेमोरी की तुलना में अधिक महत्वपूर्ण होता है, इसलिए सर्वर जीसी का उपयोग करना बेहतर होता है। हालांकि, कुछ सर्वर परिदृश्य वर्कस्टेशन जीसी के लिए अधिक अनुकूलित हो सकते हैं, उदाहरण के लिए उच्च घनत्व पर कई वेब एप्लिकेशन होस्ट करना जहां स्मृति दुर्लभ संसाधन बन जाती है।

धन्यवाद, यह बहुत आसान है, मैं ध्यान में रखूंगा - किसी भी अधिक अपडेट के लिए इस धागे का पालन करूंगा, कहा जा रहा है कि मैं बिल्कुल एएसपीनेट कोर से प्यार करता हूं :)

इसके अलावा एक .net कोर 2.1 कंसोल ऐप से भी पीड़ित हैं। निरंतर स्मृति वृद्धि। डॉकटर कंटेनरों को कम से कम अधिकतम पर सेट किया है, इसलिए यह इसे हिट करता है और पुनरारंभ होता है, जो ठीक काम कर रहा है, लेकिन यह बदसूरत है।

इस तरफ कोई खबर? ASP.Net Core v2.1 में भी हमारा समान व्यवहार है। https://github.com/aspnet/AspNetCore/commit/659fa967a1900653f7a82f02624c7c7995a3b786 प्रतिबद्धता में जो मैं देख सकता हूं उससे ऐसा लगता है कि स्मृति प्रबंधन समस्या थी जिसे v3.0 में ठीक किया जा रहा है?

@ flo8 क्या आपने 2.2 में अपग्रेड करने की कोशिश की है और व्यवहार की जाँच की है? https://dotnet.microsoft.com/download

नवीनतम 2.2 चलाना और यह समस्या भी है - केवल 1 मिलियन इन्ट्स की एक सूची बनाना और एक खाली रिसेट() लौटने से मेरे ढेर में कुछ सौ एमबी हर अनुरोध में वृद्धि होगी जब तक कि मैं स्मृति से बाहर नहीं हो जाता। ServerGarbageCollection को गलत तरीके से ठीक करने के लिए सेट करना, हालांकि यह सही फिक्स की तरह प्रतीत नहीं होता है ...

@ dre99gsx जैसा कि ऐसा लगता है कि आपको एक आसान रेप्रो मिल गया है, क्या आप एक प्रोजेक्ट और कदम साझा कर सकते हैं ताकि मैं स्थानीय रूप से वही काम कर सकूं?

इस मामले में इसे LOB भरना चाहिए लेकिन उन्हें gen2 पर एकत्र किया जाना चाहिए। कृपया यह भी साझा करें कि ओएस, मेमोरी, लोड पर मैं इसे किस वातावरण में पुन: पेश कर सकता हूं।

गुप्त प्रतिक्रिया के लिए खेद है। काफी आसान:
(विंडोज 7 64 बिट, 16 जीबी रैम, http अनुरोधों के लिए Google क्रोम, वीएस2017 समुदाय) - मुझे अभी भी इन थ्रेड्स में कोड जोड़ने की आदत है, उपस्थिति को क्षमा करें)

• एक नया .NET कोर 2.2 वेब ऐप शुरू करें
• कंट्रोलर कंस्ट्रक्टर में एक सर्विस क्लास, स्कोप्ड (कुछ खास नहीं ..) इंजेक्ट करें
• नियंत्रक की अनुक्रमणिका () क्रिया इस सेवा वर्ग की एक विधि को कॉल करें
• एक संपत्ति के साथ एक मॉडल वर्ग (डंबक्लास) बनाएं: सार्वजनिक int आईडी {प्राप्त करें; समूह;}
• सर्विस क्लास मेथड में, किसी लिस्ट को इंस्टेंट करें और उसे पॉप्युलेट करें:
  var lst = नई सूची();
  के लिए (i=0; i<10000000; i++) <--- नोट: 10 मिलियन पुनरावृत्तियां
  {
  lst.add (नया डंबक्लास () {आईडी = i});
  }
• विधि से वापस, कुछ भी वापस पास करने की आवश्यकता नहीं है, लेकिन आप उस सूची को वापस भी पास कर सकते हैं ...
• अनुक्रमणिका () नया खाली परिणाम लौटाएं ();

अब बस हर 8 सेकंड में एक्शन को कॉल करें, और प्रोफाइलर मेमोरी को ऊपर जाते हुए देखें। मेरे सिस्टम पर, मैं निजी बाइट्स पर यही देखता हूं:

आवेदन शुरू करें: 155MB
पहला http अनुरोध प्राप्त करें: 809MB
दूसरा: 1.2GB
तीसरा: 1.4GB
चौथा: 1.8GB
5वां: 2.1GB ... 2.3GB .. 2.6GB ...

अब, कुछ बिंदु पर, जीसी किक करने लगता है, लेकिन इस उदाहरण में यह कभी भी 3GB से नीचे नहीं गिरता है। जैसा कि उल्लेख किया गया है, अगर मैं सर्वरजीसी को गलत में बदल देता हूं, तो कभी भी 1GB से ऊपर नहीं उठता, हालांकि यह अभी भी ऊपर चढ़ता है और 1GB पर मंडराता है।

मुझे बताएं कि क्या इससे मदद मिलती है, और यदि आप इसे पुन: पेश कर सकते हैं। ओह, मैंने आपके जीथब पोस्ट के माध्यम से पढ़ा: "एएसपी.नेट कोर में मेमोरी प्रबंधन और पैटर्न", शानदार लेखन, योगदान के लिए धन्यवाद!

@dre99gsx👋

मुझे अभी भी इन धागों में कोड जोड़ने की आदत है, उपस्थिति को क्षमा करें)

कोई जांच नहीं :) प्रश्न: क्या आप वास्तव में पूरे नमूना आवेदन को गिटहब (फ्री रेपो) या कहीं इसी तरह रख सकते हैं? यह किसी और के लिए _संपूर्ण_ सटीक नमूना ऐप/रेपो को तुरंत क्लोन/डाउनलोड करने का सबसे आसान तरीका है, जिसके साथ आप खेल रहे हैं।

साथ ही, TaskManager का उपयोग करके मेमोरी उपयोग के स्क्रीन शॉट्स मदद करेंगे (यदि विंडोज़ पर - या इक्विव पर *nix .. जो top कमांड है ??)

अब तक का बहुत अच्छा प्रयास!

/ मैं चुपचाप इस धागे को गंभीरता से देखने के लिए वापस जाता हूं।

एक अनुस्मारक आप यहां धागे में वर्णित सभी लक्षणों के लिए कुछ डेमो और स्पष्टीकरण देख सकते हैं: https://github.com/sebastienros/memoryleak

साथ ही इनमें से प्रत्येक मुद्दे का व्यक्तिगत रूप से इलाज किया गया है और कोई भी डॉटनेट कोर __अब तक__ में बग साबित नहीं हुआ है, लेकिन अपेक्षित व्यवहार है।

@ dre99gsx अब हाल की टिप्पणी पर वापस जा रहे हैं, मैं आपसे इस धागे से एक अलग मुद्दा दर्ज करने का आग्रह करूंगा। मेरे फोन पर होने के कारण मुझे नहीं पता था कि यह "यह वाला" था;)। अपनी पहली टिप्पणी से आप कहते हैं

जब तक मेरी याददाश्त खत्म नहीं हो जाती

तो मैं आउटऑफमेमरी अपवाद की अपेक्षा करता हूं, इसलिए मैंने रेप्रो के लिए कहा। लेकिन आपकी अगली टिप्पणी में आप कहते हैं:

अब, कुछ बिंदु पर, जीसी किक करने लगता है, लेकिन यह इस उदाहरण में कभी भी 3GB से नीचे नहीं गिरता है

तो कोई स्मृति समस्या नहीं है। यह बहुत सारे कोर और बहुत सारी उपलब्ध मेमोरी वाली मशीन से विशिष्ट है। जीसी प्रबंधित ढेर को मुक्त कर देगा, लेकिन स्मृति अभी भी प्रतिबद्ध होगी क्योंकि इसे अन-प्रतिबद्ध करने का कोई कारण नहीं है (बहुत सारी उपलब्ध स्मृति)। यह .NET में एक मानक व्यवहार है, और मैं इसे उस आलेख में प्रदर्शित करता हूं जिसे मैंने इंगित किया था। आप इसे भी पढ़ सकते हैं: https://blogs.msdn.microsoft.com/maoni/2018/11/16/running-with-server-gc-in-a-small-container-scenario-part-0/

मुझे पता है कि रनटाइम टीम वर्तमान में कंटेनरों में चल रहे .NET अनुप्रयोगों को बाधित करने के तरीकों पर काम कर रही है, इसलिए यह कुछ माइक्रोसर्विस परिदृश्यों को हल करने के लिए 3.0 को लक्षित करने वाली इतनी मेमोरी का उपयोग नहीं करती है।

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

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

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

मैंने एएसपीनेट कोर 2.2 में अपना आवेदन विकसित किया है जो स्मृति रिलीज से संबंधित एक ही समस्या का सामना कर रहा है।
प्रत्येक कॉल 40-50 एमबी की सीमा में मेमोरी बढ़ाती है हर बार रिलीज नहीं होती है।

मैंने उल्लेखित टैग भी जोड़ा है ServerGarbageCollection>false
अभी भी 50 उपयोगकर्ता के लिए एक ही समस्या का सामना करना पड़ रहा है, यह इन-प्रोसेस मोड में लगभग 2GB रैम का उपयोग कर रहा है (w3wp iis कार्यकर्ता प्रक्रिया)

कृपया मदद कीजिए।

कृपया सहायता कीजिए !! ankitmori14 . के समान समस्या

@ankitmori14 , @ikourfaln - यदि आपने https://github.com/aspnet/AspNetCore/issues/1976#issuecomment -449675298 पर @sebastienros की टिप्पणी पढ़ी है और अभी भी मानते हैं कि कोई स्मृति समस्या है, तो कृपया एक नया मुद्दा दर्ज करें समस्या को पुन: उत्पन्न करने के लिए विस्तृत चरणों के साथ, साथ ही व्यवहार के बारे में आपके पास कोई अन्य जानकारी और निशान। कृपया याद रखें कि जब तक ऐप/प्रक्रिया में वास्तव में त्रुटियां नहीं होती हैं, यह संभावना नहीं है (लेकिन असंभव नहीं) कि कोई बग है। डिफ़ॉल्ट 'सर्वर' गारबेज कलेक्टर कम से कम संभव मेमोरी का उपयोग करने का प्रयास नहीं करता है; इसके बजाय यह तब शुरू होता है जब इसकी आवश्यकता होती है, जैसे कि जब स्मृति वास्तव में समाप्त हो रही हो। तो एक छोटा ऐप भी 2GB मेमोरी का उपयोग कर सकता है और यह कोई समस्या नहीं है क्योंकि अभी भी 4GB मुफ्त है।

नमस्ते,

हम इस समस्या का सामना कर रहे हैं: https://stackoverflow.com/questions/53868561/dotnet-core-2-1-hoarding-memory-in-linux

मूल रूप से स्मृति प्रक्रिया में दिनों तक बढ़ती है जब तक कि कुबेरनेट्स इसे मार नहीं देता क्योंकि 512Mb की कॉन्फ़िगर की गई सीमा तक पहुंच जाता है। काफी मजेदार है, मेमोरी डंप लेते समय, प्रक्रिया को फिर से शुरू किए बिना या कुछ भी किए बिना मेमोरी काफी कम हो गई। मेमोरी डंप की जांच करते हुए, हमने बहुत सी वस्तुओं को बिना जड़ के देखा।

हमने कल समवर्ती जीसी (यानी: पृष्ठभूमि जीसी) को भी अक्षम कर दिया था और यह अब बेहतर लगता है, लेकिन हमें पुष्टि करने के लिए कम से कम एक सप्ताह इंतजार करना होगा।

<PropertyGroup>
  <ServerGarbageCollection>false</ServerGarbageCollection>
  <ConcurrentGarbageCollection>false</ConcurrentGarbageCollection>
</PropertyGroup>

@vtortola प्रश्न, जब आपने अपने आवेदन के लिए 512Mb की सीमा को कॉन्फ़िगर किया था, तो क्या आपको इस बात का अंदाजा था कि आप कितने समवर्ती अनुरोध को संभालना चाहते हैं या परीक्षण करना चाहते हैं कि आपका ऐप गिरने से पहले कितने समवर्ती अनुरोध को संभाल सकता है ??

हमने कुछ प्रारंभिक और मोटे परीक्षण किए और जाँच की कि हम 512Mb का उपयोग करके 500 समवर्ती वेबसोकेट प्रति पॉड को संभाल सकते हैं। हम 2 पॉड्स और 1000 समवर्ती कनेक्शन के साथ घंटों तक दौड़े, जिसमें मेमोरी 150Mb से कम थी। 2 पॉड्स के साथ परिनियोजित एप्लिकेशन में किसी भी समय 150 और 300 समवर्ती कनेक्शन होते हैं, और मेमोरी पहले कुछ दिनों में 100Mb से कम से भिन्न होती है, लगभग 2 सप्ताह में 512Mb तक पहुंच जाती है। कनेक्शन की संख्या और उपयोग की गई मेमोरी के बीच कोई संबंध नहीं लगता है। 70% से अधिक कनेक्शन 10 मिनट तक चलते हैं।

क्या आप मेमोरी डंप साझा कर सकते हैं जब यह 100 एमबी और 512 एमबी पर हो, यह देखने के लिए कि कौन से उदाहरण अभी भी जीवित हैं?

मुझे डर है कि मैं डंप साझा नहीं कर सकता, क्योंकि इसमें कुकीज़, टोकन और बहुत सारे निजी डेटा शामिल हैं।

क्या आप तब स्थानीय स्तर पर तुलना कर सकते हैं? कौन सी वस्तु सबसे अधिक मेमोरी लेती है, और यदि उनकी संख्या आपके लोड से संबंधित नहीं है। जैसे अगर आपके पास 300 कनेक्शन हैं तो 3K कनेक्शन ऑब्जेक्ट नहीं होने चाहिए।

दुर्भाग्य से <ConcurrentGarbageCollection>false</ConcurrentGarbageCollection> सेट करने के परीक्षण ने मदद नहीं की और प्रक्रिया अभी भी स्मृति जमा कर रही है।

हमारे पास प्रक्रिया का एक लिनक्स डंप है, इसका विश्लेषण करने के लिए हमारे पास एकमात्र उपकरण एलएलडीबी है और हम इस मामले में बहुत नोब हैं।

घंटी बजने की स्थिति में यहां कुछ डेटा:

(lldb) eeheap -gc
Number of GC Heaps: 1
generation 0 starts at 0x00007F8481C8D0B0
generation 1 starts at 0x00007F8481C7E820
generation 2 starts at 0x00007F852A1D7000
ephemeral segment allocation context: none
         segment             begin         allocated              size
00007F852A1D6000  00007F852A1D7000  00007F853A1D5E90  0xfffee90(268430992)
00007F84807D0000  00007F84807D1000  00007F8482278000  0x1aa7000(27947008)
Large object heap starts at 0x00007F853A1D7000
         segment             begin         allocated              size
00007F853A1D6000  00007F853A1D7000  00007F853A7C60F8  0x5ef0f8(6222072)
Total Size:              Size: 0x12094f88 (302600072) bytes.
------------------------------
GC Heap Size:            Size: 0x12094f88 (302600072) bytes.

और dumpheap -stat का परिणाम: https://pastebin.com/ERN7LZ0n

आप देख सकते हैं कि कैसे ग्रेफाना स्मृति की स्थिति की रिपोर्ट कर रहा था https://stackoverflow.com/questions/53868561/dotnet-core-2-1-hoarding-memory-in-linux

हमारे पास डॉटनेट कोर में सेवाओं का एक और समूह है जो निर्दोष रूप से काम कर रहा है, हालांकि वे वेबसोकेट का उपयोग नहीं करते हैं।

@vtortola क्या आप एक नया मुद्दा बनाना चाहेंगे ताकि हम इसे फोर्क न करें। मुझे लगता है कि तथ्य यह है कि यह वेबसाकेट का उपयोग कर रहा है, यह अद्वितीय बनाता है और हमें कम से कम एक नमूना ऐप बनाने की ज़रूरत है जो आपके जैसा व्यवहार करे और इसे लंबे समय तक तनाव दे। क्या आप यह बता पाएंगे कि आपके ग्राहक वेबसोकेट के साथ क्या करते हैं, वे इससे कैसे जुड़ते हैं, और कितने समय के लिए? मैं इस तरह से एक ऐप सेट कर सकता हूं और इसे दिनों तक चला सकता हूं, और अगर मैं मेमोरी को बढ़ता हुआ देखूं तो मेमोरी डंप ले सकता हूं।

यह जीसी और कुबेरनेट्स के बीच कुछ संघर्ष भी हो सकता है, इस तरह से जीसी को चेतावनी नहीं मिलती है कि यह पॉड की सीमा के करीब है।

@richlander इसी तरह के मुद्दे पर काम कर रहा है। क्या यह मामला रिच करता है (केवल अंतिम 6 टिप्पणियां पढ़ें) आप जिस पर काम कर रहे हैं उससे संबंधित हो सकता है?

अगर इससे कोई फर्क पड़ता है, तो मेरे पास एक ही (या बहुत समान) समस्या है। मेरे पास एक दर्जन+ .net कोर 2.1 और 2.2 कंसोल ऐप हैं जो डॉकटर पर चल रहे हैं - प्रत्येक कंटेनर 512mb मेमोरी सीमा के साथ, वेबसोकेट (क्लाइंट) का भी उपयोग करता है, और ऐप्स हर ~ 3 दिनों में कंटेनर मेमोरी सीमा को हिट करते हैं। कंटेनर फिर बंद हो जाता है और पुनरारंभ होता है।

सब कुछ प्रमाणित सेवाओं का उपयोग कर रहा है, इसलिए मैं वह प्रदान नहीं कर सकता जो मेरे पास है, लेकिन मैं कुछ एक साथ रखने में सक्षम हो सकता हूं जो समस्या को पुन: उत्पन्न करने के लिए एक परीक्षण साइट का उपयोग करता है।

मेमोरी लिमिट सेट करने के लिए आप किन मापदंडों का उपयोग करते हैं? बस --memory या --memory-swap भी?

जब मैं इसका परीक्षण करता हूं, तो मैं देख सकता हूं कि इसे बहुत अच्छी तरह से ध्यान में रखा गया है, कभी भी मेरे द्वारा निर्धारित सीमा से अधिक नहीं जा रहा है, यहां तक ​​​​कि 16MiB जैसी सुपर कम सीमा के साथ, हालांकि यह पागलों की तरह डिस्क पर स्वैप करता है। और मैं एक ऐसे ऐप के साथ परीक्षण कर रहा हूं जो डीबी क्वेश्चन (ईएफ) और रेजर व्यू रेंडरिंग करता है।

@sebastienros बिल्कुल, मैंने https://github.com/aspnet/AspNetCore/issues/6803 बनाया है

कृपया मुझे बताएं कि क्या आपको और अधिक जानकारी चाहिये?

मैं वर्तमान में स्मृति समस्याओं का सामना कर रहा हूँ।

उत्पादन में एक घंटे के बाद सभी मेमोरी का उपयोग w3wp.exe प्रक्रिया द्वारा किया जाता है (.NET कोर इनप्रोसेस चल रहा है)। जीसी को वर्कस्टेशन में बदलना, मेरे लिए चाल नहीं चली।

मेमोरी डंप का विश्लेषण करने के बाद, मुझे यह समान समस्या मिली, https://github.com/aspnet/AspNetCore/issues/6102।

नवीनतम .NET कोर रन टाइम, वर्तमान में 2.2.3 में अपग्रेड करने के बाद, मैं आज बाद में उत्पादन में इसका परीक्षण करने की उम्मीद कर रहा हूं। मैं आपको बता दूंगा कि यह कैसा चल रहा है।

मुझे स्मृति उपयोग के साथ समान समस्याएं आ रही हैं। अगर मैं अपने लिनक्स कंटेनरों पर सीमा निर्धारित करता हूं, तो यह इसे ओओएम तेज बनाता है। यह विजुअल स्टूडियो में मूल टेम्पलेट्स का उपयोग करके भी होता है। एक चीज जो मैंने पाई है - कोर 2.1 और 2.2 प्रभावित हैं। कोर 2.0 नहीं है - लेकिन यह ईओएल है :(

ऊपर देखो

मुझे पता है कि रनटाइम टीम वर्तमान में कंटेनरों में चल रहे .NET अनुप्रयोगों को बाधित करने के तरीकों पर काम कर रही है, इसलिए यह कुछ माइक्रोसर्विस परिदृश्यों को हल करने के लिए 3.0 को लक्षित करने वाली इतनी मेमोरी का उपयोग नहीं करती है।

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

अफसोस की बात है कि वर्कस्टेशन मोड बिल्कुल भी मदद नहीं करता है - दुख की बात है कि मैं वास्तव में 3.0 पूर्वावलोकन या समान में से किसी एक को आजमाने की स्थिति में नहीं हूं।

@PrefabPanda सुनिश्चित करें कि आप वास्तव में वर्कस्टेशन GC मोड में चल रहे हैं यह जाँच कर कि System.Runtime.GCSettings.IsServerGC false है।

तब यह वास्तविक स्मृति रिसाव हो सकता है। एक अलग मुद्दा खोलें शायद सबसे अच्छा कदम।

@ wanton7 - धन्यवाद, मैंने दोबारा जांच की है और यह निश्चित रूप से सेट है।

@DAllanCarr - करेंगे

मैं लगभग निश्चित हूं कि यह स्मृति रिसाव नहीं है। डॉकर सेटिंग्स की तरह अधिक सही ढंग से लागू नहीं किया जा सकता है और जीसी सीमा तक पहुंचने से पहले किक नहीं करता है। मुझे पता है कि 3.0 इस अर्थ में सुधार प्रस्तुत करता है।

@richlander क्या यह समस्या कुछ ऐसी दिखती है जो 2.2 में काम नहीं करने के लिए जानी जाती है?

@PrefabPanda क्या आप अपने द्वारा उपयोग किए जा रहे सटीक docker संस्करण और docker कंपोज़ फ़ाइल को साझा करने पर ध्यान देंगे? मैं repro करने की कोशिश कर रहा हूँ, लेकिन docker और docker-compose संस्करणों के बीच मुझे इस मुद्दे को स्थानीय रूप से दोहराने में कठिनाई होती है।

@sebastienros , @richlander - मेरे पास वापस आने के लिए धन्यवाद। मैं वास्तव में इसकी प्रशंसा करता हूँ।

मेरे डॉकर संस्करण:

डॉकर डेस्कटॉप समुदाय
संस्करण 2.0.0.2 (30215)

इंजन: 18.09.1
लिखें: 1.23.2

संपूर्ण परीक्षण परियोजना संलग्न देखें:
वेबएप्लीकेशन1.ज़िप

कर्ल अनुरोधों का परीक्षण करें। ज़िप

बस के मामले में, मेरा डॉकरफाइल:

mcr.microsoft.com/dotnet/core/ aspnet से :2.2 AS आधार
वर्कडीर / ऐप
एक्सपोज़ 80
एक्सपोज़ 443

mcr.microsoft.com/dotnet/core/ sdk:2.2 AS बिल्ड से
वर्कडीर / src
कॉपी करें ["WebApplication1/WebApplication1.csproj", "WebApplication1/"]
रन डॉटनेट "WebApplication1/WebApplication1.csproj" को पुनर्स्थापित करें
कॉपी करें। .
वर्कडीर "/ src/WebApplication1"
रन डॉटनेट बिल्ड "WebApplication1.csproj" -c रिलीज़ -o /app

प्रकाशन के रूप में निर्माण से
रन डॉटनेट "WebApplication1.csproj" -c रिलीज़ -o /app . प्रकाशित करें

आधार से अंतिम के रूप में
वर्कडीर / ऐप
कॉपी - से = प्रकाशित / ऐप।
ENTRYPOINT ["डॉटनेट", "WebApplication1.dll"]

docker-compose.yml:

संस्करण: '2.4'

सेवाएं:
वेब अनुप्रयोग1:
छवि: ${DOCKER_REGISTRY-}webapplication1
mem_reservation: 128m
mem_limit: 256m
memswap_limit: 256m
सीपीयू: 1
निर्माण:
संदर्भ: ।
dockerfile: WebApplication1/Dockerfile

docker-compose-override.yml:

संस्करण: '2.4'

सेवाएं:
वेब अनुप्रयोग1:
वातावरण:
- ASPNETCORE_ENVIRONMENT=विकास
- ASPNETCORE_URLS=https://+:443;http://+:80
- ASPNETCORE_HTTPS_PORT=44329
- DOTNET_RUNNING_IN_CONTAINER=सत्य
- DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=true
- ASPNETCORE_preventHostingStartup=true
बंदरगाह:
- "50996:80"
- "44329:443"
मात्रा:
- ${APPDATA}/ASP.NET/Https:/root/.aspnet/ https:ro
- ${APPDATA}/Microsoft/UserSecrets:/root/.microsoft/us ersecrets:ro

@sebastienros - यहां तक ​​​​कि अगर कोई तरीका है तो मैं जीसी को देखने के लिए कंटेनर में एक अलग पर्यावरण चर डाल सकता हूं, यह मेरे लिए ठीक काम करेगा।

मैंने इसे स्पष्ट रूप से कॉल करने का प्रयास किया है, लेकिन यह मदद नहीं करता है - मुझे लगता है कि इसे कोड में कॉल करते समय भी यह कंटेनर/मशीन के गलत मेमोरी आकार को देखता है।

@PrefabPanda जब आपने कहा "मैंने इसे स्पष्ट रूप से कॉल करने का प्रयास किया है", क्या आप कृपया विस्तार से बता सकते हैं कि वास्तव में क्या मतलब है? यदि आपके पास एक निर्दिष्ट है, तो जीसी सही कंटेनर मेमोरी सीमा देखता है, चाहे वह स्वाभाविक रूप से ट्रिगर हो या प्रेरित हो। यदि आपने GC.Collect() को कॉल किया है, तो यह एक पूर्ण अवरोधन संग्रह करेगा; और यदि आप GC.Collect(2, GCCollectionMode.Default, true, true) करते हैं, तो यह एक पूर्ण कॉम्पैक्टिंग GC करेगा, जब यह लौटाता है कि कंटेनर की सीमा या कुछ और की परवाह किए बिना हीप सबसे छोटे आकार में संभव है।

हाय @ Maoni0 - मैंने GC.Collect(2, GCCollectionMode.Default, true, true) की कोशिश की है।

मैंने अभी एक और टिप्पणी देखी है जिसमें कहा गया है कि 256 एमबी 2.2 के लिए बहुत छोटा है, लेकिन 3.0 में 'निश्चित' हो सकता है। ऐसा लगता है कि मुझे कुछ और प्रयोग करने होंगे...

यदि आपने GC.Collect(2, GCCollectionMode.Default, true, true) आज़माया है और आपकी अपेक्षानुसार मेमोरी कम नहीं हुई है, तो इसका मतलब है कि आपके पास एक सच्ची मेमोरी लीक है। सुनिश्चित नहीं है कि आपके परिवेश में कितनी टूलींग उपलब्ध है। क्या आप एसओएस कमांड बिल्कुल चला सकते हैं? यदि ऐसा है तो आप हमेशा यह देखने के लिए देख सकते हैं कि आपके प्रेरित जीसी के बाद ढेर पर क्या रहता है

धन्यवाद @ Maoni0 - ध्यान रखें कि मैं विजुअल स्टूडियो में एक टेम्पलेट का उपयोग कर रहा हूं - मेरे द्वारा संलग्न इस परीक्षण परियोजना में सचमुच मेरा कोई कोड नहीं है। मुझे काम करने के लिए कुछ और फीडबैक मिला है, मैं संपर्क में रहूंगा। बहुत धन्यवाद।

@ Maoni0 - मैंने उच्च सीमा निर्धारित करने की कोशिश की, कोई फर्क नहीं पड़ता। ऐसा लगता है कि मुझे 3.0 पूर्वावलोकन आज़माना होगा

मैं इस मुद्दे पर टिप्पणियों को बंद करना चाहता हूं क्योंकि यह बहुत पुराना है जिसने अपने सभी मामलों को अलग-अलग मुद्दों में माना है। मैंने इस पर गलती से यह सोचकर टिप्पणी कर दी कि मैं https://github.com/aspnet/AspNetCore/issues/10200 पर टिप्पणी कर रहा हूं।

धन्यवाद