क्या मैं (और क्या मैं कभी भी करना चाहता हूं) अधिकतम हेप आकार को .NET में सेट कर सकता हूं?

Question

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

क्या यह .NET में लागू होता है? क्या आप ढेर आकार सीमा निर्धारित कर सकते हैं? क्या सीएलआर मशीन की भौतिक सीमा तक पहुंचने तक ही अपने ढेर को बढ़ता रहता है? या क्या यह कुछ सूक्ष्म कारणों से .NET में कोई मुद्दा नहीं है कि मेरे जावा ब्लिंकर्स मुझे देखने से रोकते हैं?

Answer 1

आप अधिकतम ढेर आकार को .Net में सेट नहीं कर सकते हैं जब तक आप एक प्रक्रिया में स्वयं को सीएलआर होस्ट नहीं करते।

संपादित करें: अधिकतम ढेर आकार सहित CLR की स्मृति आवंटन को नियंत्रित करने के लिए, आप clr की मेजबानी के लिए होस्टिंग एपीआई का उपयोग करें और विशेष रूप से "मेमोरी प्रबंधक इंटरफेस" का उपयोग करने की जरूरत है, कुछ स्टार्टर जानकारी यहां पाया जा सकता MSDN Magazine, column CLR Inside Out : CLR Hosting APIs

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

Answer 2

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

संपादित करें: ऐसा लगता है कि इसमें थोड़ा और अधिक है, हालांकि एक बड़ी राशि नहीं है। Rick Minerich's blog entry on GC settings और the subsequent one इस मामले के बारे में मुझसे ज्यादा नहीं जानते हैं। वे शायद आगे की जांच के लिए एक अच्छा प्रारंभिक बिंदु हैं - लेकिन वे जेवीएम में उपलब्ध स्मृति सीमाओं की तरह अधिकतर झंडे हैं।

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

Answer 3

आप System.Runtime.MemoryFailPoint पर देख सकते हैं।

Answer 4

जहां तक ​​मुझे मिला है, सीएलआर का उपयोग करते हुए .NET ऐप के control the size of the heap का कोई आसान तरीका नहीं है।

उपरोक्त लिंक केवल आधे प्रश्न का उत्तर देता है। जब मैंने इस मुद्दे पर शोध किया है, तो प्रतिक्रिया है कि "ढेर सभी उपलब्ध स्मृति का उपयोग करने के लिए बढ़ता है" जैसे कि यही कारण है कि आप अधिकतम ढेर आकार को नियंत्रित करना चाहते हैं।

ऑन (आमतौर पर जावा) सर्वर वातावरण, आप अन्य होस्ट किए गए ऐप्स की कीमत पर एक बुरी तरह से व्यवहार करने वाले ऐप को याद रखने के लिए नहीं चाहते हैं। एक सरल समाधान यह है कि ऐप की मात्रा को सीमित करने के लिए ऐप का उपयोग कर सकते हैं। यह जावा के-एक्सएमएक्स तर्क के साथ पूरा किया जाता है ताकि आप गारंटी दे सकें कि ऐप योजनाबद्ध की तुलना में अधिक उपयोग नहीं करेगा, उदाहरण के लिए -Xmx256M।चूंकि प्रारंभिकरण के दौरान ढेर पर स्मृति आवंटित करने से ऐप्स स्टार्टअप धीमा हो सकता है, जावा -Xms arg का उपयोग करता है ताकि ऐप को ऑब्जेक्ट सृजन करने के लिए प्रारंभिक समय के दौरान हेप के बड़े ब्लॉक के साथ प्रारंभ करने के लिए प्रारंभ किया जा सके, JVM के बदले में ढेर का आकार बदलना जाता है।

.Net के सीएलआर में यह क्षमता नहीं है। मुझे संदेह है कि ऐसा इसलिए है क्योंकि नेट की सीएलआर वर्चुअल मशीन नहीं है। सीएलआर एक एपीआई (काफी व्यापक, मैं जोड़ सकता हूं) होता है जो देशी। डीएलएस के एडाप्टर के रूप में कार्य करता है जो स्मृति प्रबंधन की बात करते समय निष्पादन योग्य की तरह एक दृष्टिकोण के बराबर होता है।

मैंने इस सवाल को शेयरपॉइंट विकास के बारे में पूछा है और यह सुना है कि वेब ऐप्स नामक आईआईएस मॉड्यूल के उपयोग के माध्यम से हेपसाइज को नियंत्रित करना संभव हो सकता है जिससे आप आईआईएस को किसी दिए गए वेब ऐप की याददाश्त को सीमित कर सकें। मुझे आश्चर्य है कि ऐसा इसलिए है क्योंकि आईआईएस ने दिनचर्या को अनुकूलित किया है जो नए()/malloc()/etc को प्रतिस्थापित/ओवरराइड करता है और इस प्रकार क्लाइंट ऐप्स पर इस प्रकार का नियंत्रण प्रदान कर सकता है। इसका मतलब है कि स्टैंडअलोन .Net ऐप्स भाग्य से बाहर हैं जब तक आप सी ++ में कस्टम मेमोरी मैनेजर लिखना नहीं चाहते हैं और .NET