संक्षिप्त जवाब
"मेमोरी ऑफ आउट" पॉप-अप कहता है कि निजी प्रतिबद्ध मेमोरी पर आपकी सीमा समाप्त हो रही है - एक प्रकार की वर्चुअल मेमोरी। ऐसा नहीं है कि आप RAM (भौतिक मेमोरी) से बाहर चल रहे हैं। इससे कोई फर्क नहीं पड़ता कि आपके पास कितनी उपलब्ध रैम है। बहुत सी उपलब्ध रैम होने से आप प्रतिबद्ध सीमा से अधिक नहीं हो सकते। प्रतिबद्ध सीमा आपके कुल RAM का योग है (चाहे उपयोग में हो या नहीं!) साथ ही आपके वर्तमान पेजफाइल का आकार।
इसके विपरीत, क्या "उपयोग" प्रतिबद्ध सीमा (जो कि ज्यादातर प्रक्रिया-निजी वर्चुअल एड्रेस स्पेस का निर्माण है) आवश्यक रूप से किसी भी रैम का उपयोग नहीं करता है! लेकिन OS अपनी रचना की अनुमति तब तक नहीं देगा जब तक कि यह न जान ले कि इसे स्टोर करने के लिए कुछ जगह है अगर इसे कभी जरूरत पड़े। तो आप अपने सभी रैम या अपने अधिकांश रैम का उपयोग किए बिना प्रतिबद्ध सीमा में चला सकते हैं।
यही कारण है कि आपको पेजफाइल के बिना नहीं चलना चाहिए। ध्यान दें कि पेजफाइल वास्तव में कभी नहीं लिखा जा सकता है! लेकिन यह अभी भी आपको "मेमोरी पर कम" और "मेमोरी से बाहर" त्रुटियों से बचने देगा।
इंटरमीडिएट उत्तर
Windows वास्तव में RAM से बाहर चलाने के लिए एक त्रुटि संदेश नहीं है। जो आप बाहर चल रहे हैं वह "प्रतिबद्ध सीमा" है।
प्रोसेस एक्सप्लोरर के उस संस्करण में "सिस्टम" ग्राफ का नाम खराब है। इसे "प्रतिबद्ध शुल्क" लेबल किया जाना चाहिए। (संस्करण में मैंने इसे "सिस्टम कमेटी" कहा है। बेहतर है, लेकिन फिर भी पूरी तरह से सुसंगत नहीं है।) किसी भी स्थिति में ग्राफ की "वर्तमान" ऊँचाई है जो पाठ अनुभाग में "कम चार्ज" के रूप में नीचे दिखाई देती है - " वर्तमान ", और ग्राफ की अधिकतम ऊंचाई" कमिट चार्ज "-" सीमा "का प्रतिनिधित्व करती है।
"कमिट चार्ज" वर्चुअल एड्रेस स्पेस को संदर्भित करता है जो पेजफाइल (यदि आपके पास एक है) द्वारा समर्थित है - दूसरे शब्दों में, यदि यह सब रैम में फिट नहीं हो सकता है, तो शेष पेजफाइल में जाता है। (वास के अन्य प्रकार हैं जो या तो अन्य फ़ाइलों द्वारा समर्थित हैं - जिसे "मैप्ड वैस" कहा जाता है - या जो हर समय रैम में रहना चाहिए; बाद वाले को "अप्राप्य" कहा जाता है।) "प्रतिबद्ध सीमा" अधिकतम है। "कमिट चार्ज" हो सकता है। यह आपके RAM आकार और पेजफाइल आकार के बराबर है।
आपके पास जाहिरा तौर पर कोई पेजफाइल नहीं है (मैं बता सकता हूं क्योंकि आपकी प्रतिबद्ध सीमा आपके रैम आकार के बराबर है), इसलिए प्रतिबद्ध सीमा केवल रैम आकार है।
जाहिरा तौर पर विभिन्न कार्यक्रमों + OS ने अधिकतम सभी संभव प्रतिबद्धताओं का उपयोग किया है।
यह सीधे तौर पर कुछ भी नहीं है कि रैम कितनी मुफ्त या उपलब्ध है। हां, आपके पास लगभग 4.5 जीबी रैम उपलब्ध है। इसका मतलब यह नहीं है कि आप प्रतिबद्ध सीमा को पार कर सकते हैं। आवश्यक मेमोरी रैम का उपयोग नहीं करती है और उपलब्ध रैम की मात्रा से सीमित नहीं है।
आपको पेजफाइल को या तो फिर से सक्षम करने की आवश्यकता है - यह बहुत प्रतिबद्ध का उपयोग करते हुए, मैं 16 जीबी पेजफाइल का सुझाव दूंगा, क्योंकि आप ओएस को रैम में इतना सामान रखने के लिए मजबूर नहीं करना चाहते हैं, और पेजफाइल सबसे अच्छा काम करता है अगर यह बहुत सारे मुफ्त कमरे हैं - या फिर अधिक रैम जोड़ें। बहुत अधिक। अच्छे प्रदर्शन के लिए आपको कोड और अन्य सामानों के लिए RAM में भरपूर जगह होनी चाहिए जो पेजफाइल द्वारा समर्थित नहीं है (लेकिन अन्य फ़ाइलों के लिए पृष्ठांकित किया जा सकता है)।
बहुत लंबा जवाब
(लेकिन अभी भी विंडोज इंटरनेशनल के मेमोरी मैनेजमेंट चैप्टर से बहुत कम है ...)
मान लीजिए कि एक प्रोग्राम 100 एमबी प्रोसेस-प्राइवेट वर्चुअल मेमोरी आवंटित करता है। यह "कमिट" विकल्प के साथ एक VirtualAlloc कॉल के साथ किया जाता है। इसके परिणामस्वरूप "कमिट चार्ज" में 100 एमबी की वृद्धि होगी। लेकिन यह "आवंटन" वास्तव में किसी भी रैम का उपयोग नहीं करता है! रैम का उपयोग केवल तब किया जाता है जब कुछ नए-प्रतिबद्ध वर्चुअल एड्रेस स्पेस को पहली बार एक्सेस किया जाता है।
रैम आखिरकार कैसे इस्तेमाल की जाती है
(अगर यह कभी करता है)
नए प्रतिबद्ध स्थान पर पहली बार पहुंच लगभग हमेशा एक मेमोरी राइट होगी (लिखने से पहले नव-आवंटित निजी वीएएस पढ़ना हमेशा लगभग एक प्रोग्रामिंग त्रुटि है, क्योंकि इसकी प्रारंभिक सामग्री, कड़ाई से बोल रही है, अपरिभाषित है)। लेकिन पढ़ें या लिखें, परिणाम, पहली बार जब आप नव-आवंटित वास के एक पृष्ठ को स्पर्श करते हैं, तो एक पृष्ठ दोष होता है । यद्यपि "दोष" शब्द बुरा लगता है, पृष्ठ दोष एक आभासी मेमोरी ओएस में पूरी तरह से अपेक्षित और यहां तक कि आवश्यक घटना है।
इस विशेष प्रकार के पेज फॉल्ट के जवाब में पेजर (ओएस के मेमोरी मैनेजर का हिस्सा, जिसे मैं कभी-कभी संक्षिप्त कर देता हूं। जैसा कि "एमएम" होगा):
- RAM का एक भौतिक पृष्ठ आवंटित करें (आदर्श रूप से शून्य पृष्ठ सूची से, लेकिन किसी भी स्थिति में, यह "उपलब्ध": विंडोज़, "शून्य", या स्टैंडबाय पृष्ठ सूची, जिसे वरीयता के क्रम में कहा जाता है) से आता है;
- वर्चुअल पेज के साथ भौतिक पृष्ठ को जोड़ने के लिए एक पृष्ठ तालिका प्रविष्टि भरें ; और अंत में
- पृष्ठ दोष अपवाद को खारिज करें।
जिसके बाद कोड जिसने मेमोरी रेफरेंस किया था, पेज फाल्ट को बढ़ाने वाले इंस्ट्रक्शन को फिर से निष्पादित करेगा और इस बार रेफरेंस सफल होगा।
हम कहते हैं कि पृष्ठ "कार्यशील प्रक्रिया", और RAM में "दोषपूर्ण" हो गया है। टास्क मैनेजर में यह प्रक्रिया के "निजी कामकाजी सेट" में एक-पृष्ठ (4 KB) की वृद्धि के रूप में दिखाई देगा। और उपलब्ध भौतिक स्मृति में एक-पेज की कमी। (व्यस्त मशीन पर ध्यान देना मुश्किल हो सकता है।)
नोट 1: इस पृष्ठ दोष में डिस्क से पढ़ी गई कोई भी चीज शामिल नहीं थी। प्रतिबद्ध वर्चुअल मेमोरी का कभी भी पहले से एक्सेस किया गया पेज डिस्क पर जीवन शुरू नहीं करता है; यह डिस्क पर कोई जगह नहीं इसे पढ़ने के लिए है से । यह रैम के पहले से उपलब्ध पृष्ठ में बस "भौतिक" है। सांख्यिकीय रूप से, वास्तव में, ज्यादातर पेज दोषों को रैम में हल किया जाता है, या तो उन साझा किए गए पृष्ठों को जो पहले से ही अन्य प्रक्रियाओं के लिए रैम में हैं, या पेज कैश के लिए - स्टैंडबाय या संशोधित सूचियां, या इस तरह "शून्य की मांग करें" पेजों के रूप में।
नोट 2: यह "उपलब्ध" से सिर्फ एक पृष्ठ, 4096 बाइट्स लेता है। कभी भी छुआ-छोड़े जाने से पहले प्रतिबद्ध पते की जगह को सामान्य रूप से महसूस नहीं किया जाता है - एक समय में सिर्फ एक पृष्ठ में दोषपूर्ण, जैसा कि प्रत्येक पृष्ठ को पहली बार "छुआ" जाता है। एक समय में अधिक करने में कोई सुधार, कोई लाभ नहीं होगा; यह लंबे समय के रूप में केवल n बार ले जाएगा। इसके विपरीत, जब पृष्ठों को डिस्क से पढ़ा जाना होता है, तो "रीडहेड" की कुछ मात्रा का प्रयास किया जाता है, क्योंकि डिस्क रीड में अधिकांश समय प्रति ऑपरेशन ओवरहेड में होता है, न कि वास्तविक डेटा ट्रांसफर में। "प्रतिबद्ध" राशि 100 एमबी पर रहती है; तथ्य यह है कि एक या पृष्ठों को गलत किया गया है कमिट चार्ज को कम नहीं करता।
नोट 3:मान लीजिए कि हमारे पास 4 जीबी "उपलब्ध" रैम है। इसका मतलब है कि हम रैम से बाहर होने से पहले एक मिलियन से अधिक बार (4 जीबी / 4096) के बारे में पहले से आवंटित लेकिन कभी-संदर्भित-संदर्भित मेमोरी को संदर्भित कर सकते थे। किस बिंदु पर, यदि हमारे पास डेविड कटलर और लू पेरज़ोली के रूप में पेजफाइल है, तो रैम में सबसे लंबे समय से पहले-संदर्भित पृष्ठों को डिस्क पर सहेजा जाएगा और फिर इन अधिक पृष्ठ दोषों को हल करने में उपयोग के लिए उपलब्ध कराया जाएगा। (असल में OS रैम रिक्लेमेशन मेथड शुरू करेगा जैसे "वर्किंग सेट ट्रिमिंग", उससे पहले, और पेजफाइल को लिखता है, दक्षता के लिए संशोधित पेज लिस्ट में कैश्ड और बैचेड होता है, और ...) उनमें से कोई भी Wii को प्रभावित नहीं करेगा। "प्रतिबद्ध" गिनती। हालांकि, यह "प्रतिबद्ध सीमा" के लिए प्रासंगिक है। अगर वहाँ सब के लिए जगह नहीं है "
और ऐसा होता रहता है ...
लेकिन मान लीजिए कि हमने उन मिलियन अधिक संदर्भों को नहीं किया है और अभी भी "उपलब्ध" पृष्ठों के लगभग 4GB मूल्य हैं। अब मान लेते हैं कि एक ही प्रक्रिया - या कोई अन्य, कोई फर्क नहीं पड़ता - एक और VirtualAlloc करता है, इस बार 200 एमबी का वचनबद्ध है। फिर से, यह 200 एमबी कमिट चार्ज में जुड़ जाता है, और यह किसी भी रैम को उपलब्ध नहीं करता है। बस VirtualAlloc'ating पता स्थान रैम की एक समान राशि का उपयोग नहीं करता है, और कम "उपलब्ध" रैम होने से आप अपने पते के स्थान की सीमा को सीमित नहीं कर सकते हैं जो आप VirtualAlloc कर सकते हैं (न ही उच्च उपलब्ध रैम में वृद्धि होती है)।
(ठीक है, ठीक है ... एक ओवरहेड का छोटा सा हिस्सा है, जो एक (पृष्ठ-दर-पृष्ठ) की राशि है जो प्रत्येक 2 एमबी (4 एमबी यदि आप एक x86, गैर-पीएई प्रणाली पर हैं) के लिए एक पृष्ठ तालिका के लिए उपयोग किया जाता है वर्चुअल एड्रेस स्पेस आवंटित किया गया है, और प्रत्येक वस्तुतः सन्निहित सीमा के लिए कुछ दसियों बाइट्स का "वर्चुअल एड्रेस डिस्क्रिप्टर" है।)
इस तरह से यह संभव है - और आम! - केवल थोड़ी मात्रा में रैम का उपयोग करते हुए "कमिट चार्ज" का उपयोग करना।
इसलिए, यदि "एड्रेसिंग" वर्चुअल एड्रेस स्पेस रैम का उपयोग नहीं करता है, तो एक सीमा क्यों होनी चाहिए?
क्योंकि "कमिट चार्ज" भविष्य में भंडारण स्थान के संभावित उपयोग का प्रतिनिधित्व करता है। "प्रतिबद्ध सीमा" इस तरह के आवंटन को रखने के लिए उपलब्ध भंडारण की कुल मात्रा (रैम + पेजफाइल स्पेस) का प्रतिनिधित्व करती है, क्या उन्हें वास्तव में संदर्भित किया जाना चाहिए और कहीं से भी स्टोर करने की आवश्यकता है।
जब एमएम एक VirtualAlloc अनुरोध को मंजूरी देता है, तो यह आशाजनक है - "एक प्रतिबद्धता बना रहा है" - कि बाद में आवंटित क्षेत्र तक पहुंच सभी मेमोरी सफल हो जाएगी; वे पृष्ठ दोष में परिणाम कर सकते हैं लेकिन दोष सभी को हल करने में सक्षम होंगे, क्योंकि उन सभी पृष्ठों की सामग्री को रखने के लिए पर्याप्त भंडारण है, चाहे वह रैम में हो या पेजफाइल में। Mm यह जानता है क्योंकि यह जानता है कि कितना संग्रहण स्थान है (प्रतिबद्ध सीमा) और कितना पहले से ही "प्रतिबद्ध" (वर्तमान प्रतिबद्ध प्रभार) है।
(लेकिन उन सभी पृष्ठों को आवश्यक रूप से अभी तक एक्सेस नहीं किया गया है, इसलिए आवश्यक राशि के साथ जाने के लिए भंडारण की वास्तविक आवश्यकता नहीं है, किसी भी समय।)
तो ... "सिस्टम मेमोरी से बाहर है" के बारे में क्या?
यदि आप VirtualAlloc और वर्तमान कमिट चार्ज के लिए प्रयास करते हैं, तो अनुरोधित आवंटन आकार आपको प्रतिबद्ध सीमा पर ले जाएगा, और OS पेजफाइल का विस्तार नहीं कर सकता है ताकि कमिट सीमा बढ़े ... आपको "मेमोरी से बाहर" पॉप मिलता है- अप, और प्रक्रिया VirtualAlloc कॉल विफल देखता है। अधिकांश कार्यक्रम बस अपने हाथों को फेंक देंगे और उस बिंदु पर मर जाएंगे। कुछ आँख बंद करके यह मान लेंगे कि कॉल सफल हुआ, और बाद में विफल हो गया जब उन्होंने उस क्षेत्र को संदर्भित करने का प्रयास किया जिसे उन्होंने सोचा था कि उन्होंने आवंटित किया था।
फिर से (पुनरावृत्ति के लिए खेद है): इससे कोई फर्क नहीं पड़ता कि आपके पास कितनी उपलब्ध रैम है। ओएस ने वादा किया है कि रैम या पेजफाइल स्पेस जरूरत पड़ने पर उपलब्ध होगा , लेकिन यह वादा "उपलब्ध" से घटाना नहीं है। उपलब्ध रैम का उपयोग केवल प्रतिबद्ध वीएम द्वारा किया जाता है, जब इसे पहली बार संदर्भित किया जाता है, जो कि इसका कारण "दोषपूर्ण" होता है ... अर्थात भौतिक स्मृति में एहसास होता है। और बस (= आवंटित) आभासी स्मृति ऐसा नहीं करता है। यह केवल निशुल्क वर्चुअल एड्रेस स्पेस लेता है और इससे यूजेबल वर्चुअल एड्रेस स्पेस बनाता है।
लेकिन "मेमोरी के बाहर" मामले में प्रतिबद्ध मेमोरी के लिए आवंटन का अनुरोध किया गया है, और ओएस ने इस नीव अनुरोध के आकार में वर्तमान प्रतिबद्ध शुल्क को जोड़ दिया है ... और पाया कि कुल प्रतिबद्ध सीमा से अधिक है। इसलिए यदि OS ने इस नए को मंजूरी दे दी, और उसके बाद उस सभी स्थान को संदर्भित किया गया, तो इसे स्टोर करने के लिए कोई वास्तविक स्थान (RAM + पेजफाइल) नहीं होगा।
ओएस इसकी अनुमति नहीं देगा। यह सबसे खराब स्थिति में रखने के लिए जगह की तुलना में अधिक वास को आवंटित करने की अनुमति नहीं देगा - भले ही यह सभी दोषपूर्ण हो जाए। " यही "प्रतिबद्ध सीमा" का उद्देश्य है।
मैं आपको तीन बार बताता हूं मैं आपको तीन बार बताता हूं मैं आपको तीन बार बताता हूं: "उपलब्ध" रैम की मात्रा कोई फर्क नहीं पड़ता। कि प्रतिबद्ध वर्चुअल स्पेस वास्तव में अभी तक सभी स्टोरेज स्पेस का उपयोग नहीं कर रहा है, इससे कोई फर्क नहीं पड़ता। वर्चुअल आवंटन में विंडोज तब तक "कमिट" नहीं कर सकता, जब तक कि वह भविष्य में '' '' सभी '' दोषपूर्ण '' न हो जाए।
ध्यान दें कि "मैप्ड" नामक एक अन्य प्रकार का vas है, जो मुख्य रूप से कोड के लिए और बड़ी डेटा फ़ाइलों तक पहुंच के लिए उपयोग किया जाता है, लेकिन यह "प्रतिबद्ध शुल्क" के लिए चार्ज नहीं किया जाता है और "प्रतिबद्ध सीमा" द्वारा सीमित नहीं है। ऐसा इसलिए है क्योंकि यह अपने स्वयं के भंडारण क्षेत्र के साथ आता है, जो फाइलें "मैप" की जाती हैं। "मैप्ड" vas की एकमात्र सीमा मैप की गई फ़ाइलों के लिए आपके पास मौजूद डिस्क स्थान की मात्रा है, और आपकी प्रक्रिया में मुफ्त vas की मात्रा उन्हें मैप करने के लिए है।
लेकिन जब मैं सिस्टम को देखता हूं, तो मैं अभी तक प्रतिबद्ध सीमा पर नहीं हूं?
यह मूल रूप से माप और रिकॉर्ड रखने की समस्या है। VirtualAlloc कॉल के पहले ही प्रयास करने और विफल होने के बाद आप सिस्टम को देख रहे हैं।
मान लीजिए कि आपके पास 500 एमबी की प्रतिबद्ध सीमा बची है और कुछ प्रोग्राम ने VirtualAlloc 600 एमबी की कोशिश की है। प्रयास विफल हो जाता है। फिर आप सिस्टम को देखते हैं और कहते हैं "क्या? अब भी 500 एमबी बाकी है!" वास्तव में तब तक और भी बहुत कुछ हो सकता है, क्योंकि विचाराधीन प्रक्रिया संभवतः उस बिंदु से पूरी तरह से चली गई है, इसलिए इसकी पूर्व-आवंटित प्रतिबद्ध मेमोरी को छोड़ दिया गया है।
मुसीबत यह है कि आप समय में पीछे मुड़कर नहीं देख सकते हैं कि इस समय जो प्रतिबद्ध प्रभार था उसका आवंटन प्रयास किया गया था। और आपको यह भी पता नहीं है कि प्रयास के लिए कितनी जगह थी। इसलिए आप निश्चित रूप से यह नहीं देख सकते हैं कि प्रयास विफल क्यों हुआ, या इसे काम करने की अनुमति देने के लिए कितनी अधिक "प्रतिबद्ध सीमा" की आवश्यकता होगी।
मैंने देखा है "सिस्टम मेमोरी पर कम चल रहा है "। वह क्या है?
यदि उपरोक्त मामले में ओएस पेजफाइल का विस्तार कर सकता है (यानी आप इसे डिफ़ॉल्ट "सिस्टम प्रबंधित" सेटिंग पर छोड़ देते हैं, या आप इसे प्रबंधित करते हैं, लेकिन आप प्रारंभिक से बड़ा करने के लिए अधिकतम सेट करते हैं, और पर्याप्त डिस्क स्थान है), और इस तरह के विस्तार से VirtualAlloc कॉल को सफल होने देने के लिए प्रतिबद्ध सीमा पर्याप्त रूप से बढ़ जाती है, फिर ... Mm पेजफाइल का विस्तार करता है, और VirtualAlloc कॉल सफल होता है।
और जब आप देखते हैं कि "सिस्टम कम मेमोरी पर चल रहा है"। यह एक प्रारंभिक चेतावनी है कि अगर चीजें बिना शमन के जारी रहती हैं, तो आप जल्द ही "स्मृति से बाहर" चेतावनी देखेंगे। कुछ ऐप्स को बंद करने का समय। मैं आपकी ब्राउज़र विंडो से शुरू करूँगा।
और आपको लगता है कि यह अच्छी बात है? पेजफाइल विस्तार बुराई है !!!
नहीं, यह नहीं है। देखें, OS वास्तव में मौजूदा फ़ाइल का "विस्तार" नहीं करता है। यह सिर्फ एक नई सीमा आवंटित करता है। प्रभाव किसी भी अन्य गैर-सन्निहित फ़ाइल की तरह है। पुरानी पेजफाइल सामग्री वहीं रहती है, जहां वे होती हैं; वे एक नई जगह या ऐसा कुछ भी कॉपी करने की जरूरत नहीं है। चूंकि पेजफाइल आकार की तुलना में अधिकांश पेजफाइल आईओ अपेक्षाकृत छोटे विखंडू में हैं, इसलिए संभावना है कि किसी भी दिए गए हस्तांतरण को एक सीमा पार कर जाएगी वास्तव में बहुत दुर्लभ हैं, इसलिए विखंडन बहुत चोट नहीं पहुंचाता है जब तक कि यह वास्तव में अत्यधिक न हो।
अंत में, एक बार एक्सटेंशन में "प्रतिबद्ध" स्थान रखने वाली सभी प्रक्रियाओं ने छोड़ दिया है (ओएस शटडाउन में अगर जल्दी नहीं), तो विलुप्त हो रहे लोगों को चुपचाप मुक्त कर दिया जाता है और पेजफाइल अपने पिछले आकार और आवंटन पर वापस आ जाएगा - यदि यह पहले से ही सन्निहित था, तो फिर से है
इसलिए पेजफाइल विस्तार की अनुमति देना पूरी तरह से नि: शुल्क सुरक्षा जाल के रूप में कार्य करता है: यदि आप इसे अनुमति देते हैं, लेकिन सिस्टम को कभी भी इसकी आवश्यकता नहीं होती है, तो सिस्टम अक्सर "पेजफाइल का लगातार विस्तार और अनुबंध" नहीं करेगा जैसा कि अक्सर दावा किया जाता है, इसलिए यह कुछ भी खर्च नहीं करेगा । और अगर आपको कभी इसकी आवश्यकता होती है, तो यह आपको "वर्चुअल मेमोरी से बाहर" त्रुटियों के साथ क्रैश होने वाले ऐप्स से बचाएगा।
लेकिन लेकिन लेकिन ...
मैंने दर्जनों वेब साइटों पर पढ़ा है कि यदि आप पेजफाइल विस्तार की अनुमति देते हैं तो विंडोज लगातार पेजफाइल का विस्तार और अनुबंध करेगा, और इससे पेजफाइल के विखंडन होने तक परिणाम होगा।
वे सिर्फ गलत हैं।
यदि आपने "मेमोरी पर कम चलना" (या पुराने संस्करणों में, "वर्चुअल मेमोरी पर कम चलना)" पॉप-अप देखा है, तो ओएस ने कभी भी आपके पेजफाइल का विस्तार नहीं किया है।
यदि आप उस पॉप-अप को देखते हैं, तो यह बताता है कि आपका प्रारंभिक पेजफाइल आकार बहुत छोटा है। (मैं इसे अधिकतम देखे गए उपयोग के बारे में 4x पर सेट करना पसंद करता हूं; अर्थात "% पेजफाइल उपयोग शिखर" परफ़ॉर्म काउंटर 25% से कम होना चाहिए। कारण: पेजफाइल अंतरिक्ष किसी भी अन्य ढेर की तरह प्रबंधित होता है और यह बहुत सारे मुक्त स्थान के साथ सबसे अच्छा काम करता है। खेलने के लिए)
लेकिन वे सिर्फ क्यों नहीं ...
कोई यह तर्क दे सकता है कि ओएस को बस आवंटन होने देना चाहिए और फिर पृष्ठ दोष को हल करने के लिए कोई रैम उपलब्ध नहीं होने पर संदर्भ को विफल होने दें । दूसरे शब्दों में, ऊपर जहां हमने बताया कि प्रारंभिक पृष्ठ दोष कैसे काम करता है, क्या होगा अगर "उपलब्ध रैम के भौतिक पेज को आवंटित करें" (चरण 1) नहीं किया जा सकता था क्योंकि कोई भी उपलब्ध नहीं था, और कोई जगह नहीं थी किसी भी चीज को उपलब्ध कराने के लिए पृष्ठ पर छोड़ दिया?
तब पेज पेज की गलती को हल करने में पेजर असमर्थ होगा। इसे अपवाद (पृष्ठ दोष) को अनुमति दी जानी चाहिए कि दोषपूर्ण थ्रेड को वापस रिपोर्ट किया जाए, संभवतः कुछ अन्य अपवाद कोड में बदल दिया जाए।
डिज़ाइन दर्शन यह है कि यदि आप प्रतिबद्ध सीमा से बाहर हैं, तो VirtualAlloc एक पते के बजाय शून्य (तकनीकी रूप से एक NULL पॉइंटर) लौटाएगा, और प्रोग्रामर से यह जानना पूरी तरह से उचित होगा कि एक VirtualAlloc कॉल विफल हो जाए। इसलिए प्रोग्रामर्स से अपेक्षा की जाती है कि वे उस मामले की जाँच करें और जवाब में कुछ उचित करें (जैसे कि आप उस बिंदु तक अपने काम को सहेजने का मौका दें, और फिर कार्यक्रम "शान से" समाप्त करें)। (प्रोग्रामर: आप मॉलॉक, नई, आदि से एक पूर्ण सूचक वापसी के लिए जांच करते हैं, हाँ? फिर आप इस से क्यों नहीं?)
लेकिन प्रोग्रामर को यह उम्मीद नहीं करनी चाहिए कि एक साधारण मेमोरी संदर्भ जैसे
i = 0; // initialize loop counter
विफल हो सकता है - यदि यह सफलतापूर्वक प्रतिबद्ध पते स्थान के क्षेत्र में नहीं है। (या पते की जगह को मैप किया, उस बात के लिए।) लेकिन ऐसा हो सकता है यदि "overcommitted आवंटित करने की अनुमति दें, स्मृति संदर्भ को विफल होने दें" दर्शन का पालन किया गया था।
दुर्भाग्य से, ऊपर कोड की लाइन में एक की तरह एक स्मृति संदर्भ एक बुरा स्थिति लौटने का एक सुविधाजनक तरीका नहीं है! वे बस काम करने वाले हैं , जैसे जोड़ और घटाव। इस तरह की विफलताओं को रिपोर्ट करने का एकमात्र तरीका अपवाद के रूप में होगा। तो उन्हें संभालने के लिए प्रोग्रामर को एक अपवाद हैंडलर में पूरे कार्यक्रम को लपेटना होगा। (कोशिश ... पकड़ और वह सब।)
यह किया जा सकता है ... लेकिन हैंडलर के लिए यह जानना मुश्किल होगा कि उन अपवादों के जवाब में "सही काम" कैसे किया जाए, क्योंकि कोड में बहुत सारे, जहां वे पैदा हो सकते हैं, कई बिंदु होंगे। (विशेष रूप से, वे VirtualAlloc'd मेमोरी के लिए हर मेमोरी रेफरेंस में पैदा हो सकते हैं, मैलोडोक या नए के साथ आवंटित मेमोरी ... और सभी स्थानीय वैरिएबल्स के लिए, क्योंकि स्टैक VirtualAlloc'd भी है।)
संक्षेप में, इन मामलों में कार्यक्रम को शालीनतापूर्वक विफल करना बहुत कठिन होगा।
यह बहुत आसान है, दूसरी ओर, VirtualAlloc (या मैल्क या नए से वापसी सूचक की जांच के लिए, इस मामले के लिए, हालांकि वे वास्तव में एक ही चीज नहीं हैं) और फिर कुछ उचित करते हैं ... जैसे कि जाने की कोशिश न करें पर और जो कुछ भी यह कार्यक्रम था, उसके लिए उस आभासी स्थान की आवश्यकता थी। और शायद उपयोगकर्ता से पूछें कि क्या वे अब तक अपना काम बचाना चाहते हैं, यदि कोई हो। (दी, अभी तक बहुत सारे ऐप इतना भी करने से परेशान नहीं हैं।)
प्रतिबद्ध के अन्य उपयोगकर्ता
संयोग से, "प्रतिबद्ध सीमा" ओएस के विभिन्न आवंटन जैसे कि पृष्ठांकित और नॉनपेजेड पूल, पीएफएन सूची, आदि द्वारा कम नहीं की जाती है; जैसा कि वे होते हैं, केवल चार्ज करने के लिए शुल्क लिया जाता है। और न ही वीडियो रैम, या यहां तक कि वीडियो रैम "विंडो" के आकार से प्रभावित होने पर चार्ज या प्रतिबद्ध सीमा है।
इसे स्वयं परखें
आप इन सभी को SysInternals साइट के टेस्टलिमिट टूल से डेमो कर सकते हैं। विकल्प -m प्रतिबद्ध पते की जगह आवंटित करेगा, लेकिन इसे "स्पर्श" नहीं करेगा, इसलिए रैम का आवंटन नहीं होगा। जबकि विकल्प -d पृष्ठों का संदर्भ देगा और दोनों के संदर्भ भी देगा, जिससे दोनों ही कमिट चार्ज बढ़ेंगे और रैम में कमी आएगी।
संदर्भ
रुसिनोविच, सोलोमन और इओन्सकु द्वारा विंडोज इंटर्नल । यहां तक कि प्रदर्शन भी हैं जो आपको टेस्टीलेट टूल का उपयोग करके इन सभी बिंदुओं को साबित करने की अनुमति देते हैं। हालांकि, मुझे आपको चेतावनी देनी चाहिए कि यदि आपको लगता है कि यह लंबा था, तो चेतावनी दी जाए: अकेले एमएम अध्याय 200 पृष्ठों का है; ऊपर एक सरल संस्करण है। (कृपया परिचय में "आभार" अनुभाग पर भी नज़र डालें।)
MSDN VirtualAlloc प्रलेखन भी देखें
