हम स्मृति प्रबंधक का उपयोग क्यों करते हैं?

Question

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

मॉलोक कॉल को सहेजने का तर्क पर्याप्त है क्योंकि मैलोक स्वयं मेमोरी मैनेजर है। एकमात्र प्रदर्शन लाभ मैं कारण कर सकता हूं जब हम जानते हैं कि सिस्टम हमेशा एक ही आकार की स्मृति मांगता है।

या मेमोरी मैनेजर होने का कारण यह है कि फ्री ओएस को स्मृति वापस नहीं करता है लेकिन सूची में सहेजता है। इसलिए प्रक्रिया के जीवनकाल में, अगर हम विखंडन के कारण मॉलोक/मुक्त करते रहें तो प्रक्रिया का ढेर उपयोग बढ़ सकता है।

Answer 1

हमारे पास अंतर्निहित लोगों के बजाय कस्टम मेमोरी प्रबंधक क्यों हैं?

नंबर एक कारण यह है कि कोडबेस मूल रूप से 20-30 साल पहले लिखा गया था जब प्रदान किया गया कोई भी अच्छा नहीं था और कोई भी इसे बदलने की हिम्मत नहीं करता था।

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

Answer 2

ऐसे कई कारण हैं जिन्हें हम ऐसा करना चाहते हैं और यह वास्तव में एप्लिकेशन पर निर्भर करता है। वास्तव में आपके द्वारा वर्णित सभी कारण मान्य हैं।

मैंने एक बार एक बहुत ही सरल मेमोरी मैनेजर बनाया जो साझा करने के लिए साझा_प्टर आवंटन का ट्रैक रखता था ताकि मुझे यह देखने के लिए कि एप्लिकेशन अंत में ठीक से क्या नहीं छोड़ा जा रहा था।

मैं आपके रनटाइम पर चिपकूंगा जबतक कि आपको ऐसा कुछ नहीं चाहिए जो वह प्रदान नहीं करता है।

Answer 3

सी और सी ++ को छीनने के लिए डिज़ाइन किया गया है। वे ऐसा नहीं करते हैं जिसे स्पष्ट रूप से नहीं पूछा जाता है, इसलिए जब कोई प्रोग्राम स्मृति की मांग करता है, तो उस स्मृति को वितरित करने के लिए न्यूनतम संभव प्रयास प्राप्त होता है।

दूसरे शब्दों में, यदि आपको इसकी आवश्यकता नहीं है, तो आप इसके लिए भुगतान नहीं करते हैं।

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

Answer 4

स्मृति प्रबंधक का उपयोग मूल रूप से को आपके स्मृति आरक्षण को प्रबंधित करने के लिए किया जाता है। आम तौर पर प्रक्रियाओं की सीमित मात्रा में स्मृति (32 बिट सिस्टम में 4 जीबी) तक पहुंच होती है, इससे आपको कर्नेल के लिए आरक्षित वर्चुअल मेमोरी स्पेस को घटा देना होगा (आपके ओएस कॉन्फ़िगरेशन के आधार पर 1 जीबी या 2 जीबी)। इस प्रकार, वस्तुतः प्रक्रिया के पास पहुंच है 3 जीबी मेमोरी का कहना है जिसका उपयोग इसके सभी सेगमेंट (कोड, डेटा, बीएसएस, ढेर और ढेर) को पकड़ने के लिए किया जाएगा।

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

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

Answer 5

आपने अपने कई प्रश्नों में संक्षेप में स्पर्श किया है कि आप अपने प्रश्न में मेमोरी मैनेजर का उपयोग क्यों करेंगे।

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

यह एक बड़ा सवाल है। किसी भी एप्लिकेशन में एक मेमोरी मैनेजर जेनेरिक (मॉलोक की तरह) हो सकता है या यह अधिक विशिष्ट हो सकता है। मेमोरी मैनेजर जितना अधिक विशिष्ट हो जाता है, यह उस विशिष्ट कार्य पर अधिक कुशल होने की संभावना है जो इसे पूरा करना है।

इस बेहद सरलीकृत उदाहरण लें: "। कस्टम स्मृति allocator"

#define MAX_OBJECTS 1000 

Foo globalObjects[MAX_OBJECTS]; 

int main(int argc, char ** argv) 
{ 
    void * mallocObjects[MAX_OBJECTS] = {0}; 
    void * customObjects[MAX_OBJECTS] = {0}; 

    for(int i = 0; i < 1000; ++i) 
    { 
    mallocObjects[i] = malloc(sizeof(Foo)); 
    customObjects[i] = &globalObjects[i]; 
    } 
} 

ऊपर है कि इस वैश्विक वस्तु सूची हमारे है मैं नाटक कर रहा हूँ में यह सिर्फ इतना है कि मैं जो समझा रहा हूं उसे सरल बनाना।

जब आप मॉलोक के साथ आवंटित करते हैं तो कोई गारंटी नहीं है कि यह पिछले आवंटन के ठीक बाद है। मॉलोक एक सामान्य उद्देश्य आवंटक है और उस पर एक अच्छा काम करता है लेकिन यह आवश्यक नहीं है कि प्रत्येक एप्लिकेशन के लिए सबसे प्रभावी विकल्प बनें।

एक कस्टम आवंटक के साथ आप 1000 कस्टम ऑब्जेक्ट्स के लिए कमरे आवंटित करने में सक्षम हो सकते हैं और चूंकि वे एक निश्चित आकार हैं जो आपको विखंडन को रोकने और कुशलतापूर्वक उस ब्लॉक को आवंटित करने के लिए आवश्यक स्मृति की सटीक मात्रा लौटाते हैं।

मेमोरी अबास्ट्रक्शन और कस्टम मेमोरी आवंटकों के बीच अंतर भी है। एसटीएल आवंटक तर्कसंगत रूप से एक अमूर्त मॉडल हैं और कस्टम मेमोरी आवंटक नहीं हैं।

कस्टम allocators पर कुछ अधिक जानकारी के लिए इस लिंक पर एक नज़र डालें और क्यों वे उपयोगी होते हैं: gamedev.net link

Answer 6

malloc एक सामान्य प्रयोजन संभाजक है - "धीमा नहीं""हमेशा तेज" से ज्यादा महत्वपूर्ण है।

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

आवंटन
वर्तमान हार्डवेयर पर, प्रदर्शन के लिए यह आसानी से सबसे महत्वपूर्ण कारक के इलाके:

---

malloc के लिए कॉल के संख्या के अलावा, वहाँ अन्य प्रासंगिक विशेषताएँ हैं। एक एप्लिकेशन के पास पहुंच पैटर्न का अधिक ज्ञान होता है और तदनुसार आवंटन को अनुकूलित कर सकता है।

multithreading
एक सामान्य प्रयोजन संभाजक अलग धागे से malloc के लिए कॉल और निःशुल्क अनुमति देनी होगी। इसके लिए आमतौर पर लॉक या समान समवर्ती हैंडलिंग की आवश्यकता होती है। यदि ढेर बहुत व्यस्त है, तो इससे बड़े पैमाने पर विवाद होता है।

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

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

पिछली बार मैंने allocators में गहरी देखा (जो शायद आधे दशक अतीत है), आम सहमति है कि अनुभवहीन प्रयास विखंडन अक्सर कभी नहीं धीमी गति से शासन के साथ संघर्ष को कम करने के लिए था।

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

resilence और निदान
अंतिम नहीं कम से कम डिफ़ॉल्ट संभाजक के निदान और आत्म सुरक्षा क्षमताओं कई अनुप्रयोगों के लिए पर्याप्त नहीं हो सकता।

Answer 7

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

किसी प्रक्रिया में स्मृति की मरम्मत के दौरान मंदी से बचने के लिए, एक सर्वर प्रकार का अनुप्रयोग एप्लिकेशन के लिए कई प्रक्रियाओं का उपयोग कर सकता है, ताकि एक प्रक्रिया को दोबारा करने के दौरान, अन्य प्रक्रिया (एस) अधिक भार लेती है।