मेरी समझ से, यह संभव नहीं है। मेमोरी मैपिंग ऑपरेटिंग सिस्टम द्वारा नियंत्रित है। कर्नेल निर्णय लेगा कि उपलब्ध स्मृति को सर्वोत्तम तरीके से कैसे उपयोग करें, लेकिन यह कुल मिलाकर सिस्टम को देखता है। मुझे पता नहीं है कि प्रक्रिया स्तर पर कैश के लिए कोटा समर्थित हैं (कम से कम, मैंने लिनक्स या बीएसडी में ऐसे एपीआई नहीं देखे हैं)।
वहाँ madvise गिरी संकेत दे रहा है, लेकिन यह एक प्रक्रिया के लिए इस्तेमाल किया कैश को सीमित करने का समर्थन नहीं करता। आप इसे MADV_DONTNEED जैसे संकेत दे सकते हैं, जो अन्य अनुप्रयोगों के कैश पर दबाव कम कर देगा, लेकिन मुझे उम्मीद है कि यह अच्छा से ज्यादा नुकसान करेगा, क्योंकि यह संभवतः कैशिंग को कम कुशल बना देगा, जिससे अधिक आईओ लोड हो जाएगा कुल मिलाकर सिस्टम पर।
मुझे केवल दो विकल्प दिखाई देते हैं। ओएस स्तर पर समस्या को हल करने की कोशिश कर रहा है, और दूसरा इसे एप्लिकेशन स्तर पर हल करना है।
ओएस स्तर पर, मैं दो विकल्प देखेंगे:
- आप एक आभासी मशीन चला सकते हैं, लेकिन सबसे अधिक संभावना यह नहीं है कि आप क्या चाहते। मैं यह भी उम्मीद करता हूं कि यह समग्र सिस्टम प्रदर्शन में सुधार नहीं करेगा। फिर भी, यह स्मृति खपत पर ऊपरी सीमा को परिभाषित करने का कम से कम एक तरीका होगा।
- डोकर एक और विचार है कि मन में आता है, यह भी ओएस स्तर पर काम कर रही है, लेकिन मेरी जानकारी के अनुसार, यह कैश पर कोटा परिभाषित करने के लिए समर्थन नहीं करता। मुझे नहीं लगता कि यह काम करेगा।
यह केवल एक विकल्प छोड़ देता है, जो एप्लिकेशन स्तर को देखना है। स्मृति मैप की गई फ़ाइलों का उपयोग करने के बजाय, आप स्पष्ट फ़ाइल सिस्टम संचालन का उपयोग कर सकते हैं। यदि आपको बफर पर पूरा नियंत्रण होना चाहिए, तो मुझे लगता है कि यह एकमात्र व्यावहारिक विकल्प है। यह मेमोरी मैपिंग की तुलना में अधिक काम है, और यह बेहतर प्रदर्शन करने की भी गारंटी नहीं है।
आप स्मृति मानचित्रण के साथ रहना चाहते हैं, तो आप भी स्मृति में और अन्य भागों unmap फ़ाइल के केवल भागों मैप कर सकते हैं जब आप अपने स्मृति कोटे से अधिक। यह भी एक ही समस्या है जैसे स्पष्ट फ़ाइल आईओ संचालन (अधिक कार्यान्वयन कार्य और एक अच्छी कैशिंग रणनीति खोजने के लिए गैर-तुच्छ ट्यूनिंग)।
कहा करने के बाद, आप कैश स्मृति उपयोग को सीमित करने की आवश्यकता पर सवाल खड़ा कर सकता है। मैं उम्मीद करता हूं कि कर्नेल मेमोरी संसाधनों को एक अच्छे तरीके से आवंटित करने में एक बहुत अच्छी नौकरी करता है। कम से कम, यह उन समाधानों से बेहतर होगा जो मैंने स्केच किए हैं। (स्पष्ट फ़ाइल IO, साथ ही एक आंतरिक कैश, तेज़ हो सकता है, लेकिन यह कार्यान्वित करने और ट्यून करने के लिए छोटा नहीं है। यहां, व्यापार-ऑफ़ की तुलना है: mmap() vs. reading blocks।)
परीक्षण के दौरान, आप एप्लिकेशन चला सकते हैं ionice -c 3 और nice -n 20 के साथ अन्य उत्पादक अनुप्रयोगों पर प्रभाव को कम करने के लिए। nocache नामक टूल भी है।मैंने इसका कभी भी उपयोग नहीं किया, लेकिन अपने दस्तावेज के माध्यम से पढ़ते समय, यह आपके प्रश्न से कुछ हद तक संबंधित लगता है।
बफर कैश को कर्नेल द्वारा स्वचालित रूप से बनाए रखा जाता है। अपने आप से स्मृति त्रुटियों का कारण नहीं होगा। आप इसे अपने आप क्यों नियंत्रित करना चाहते हैं? – fukanchik
@ फ़ुकंचिक मेरे पर्यावरण के कारण, मुझे पता होना चाहिए कि मेरी प्रक्रिया कितनी मेमोरी का उपयोग करेगी, और इसे सीमित करें। इसके अतिरिक्त, मेरे पास एक मशीन है जिसमें 100 जीबी मेमोरी है, लेकिन मैं सॉफ्टवेयर का परीक्षण करना चाहता हूं जैसे मशीन में केवल 1 जीबी मेमोरी है। – JaredC
मुझे लगता है कि आपकी सबसे अच्छी शर्त एप्लिकेशन के भीतर से इसे संभालना नहीं है, बल्कि इसके बजाय ओएस स्तर पर है। यहां एक अच्छा प्रारंभिक बिंदु है: https://unix.stackexchange.com/questions/44985/limit-memory-usage-for-a-single-linux-process – Frank