सॉफ्टवेअर ओएस पर बहुत सरल आधार पर चलते हैं - उन्हें मेमोरी की आवश्यकता होती है। डिवाइस ओएस इसे रैम के रूप में प्रदान करता है। आवश्यक मेमोरी की मात्रा भिन्न हो सकती है - कुछ सॉफ्टवेयर्स को विशाल मेमोरी की आवश्यकता होती है, कुछ को पैलेट्री मेमोरी की आवश्यकता होती है। अधिकांश (यदि सभी नहीं) उपयोगकर्ता ओएस पर एक साथ कई एप्लिकेशन चलाते हैं, और यह देखते हुए कि मेमोरी महंगी है (और डिवाइस का आकार सीमित है), उपलब्ध स्मृति की मात्रा हमेशा सीमित होती है। इसलिए यह देखते हुए कि सभी सॉफ्टवेयर्स को एक निश्चित मात्रा में RAM की आवश्यकता होती है, और उन सभी को एक ही समय पर चलाने के लिए बनाया जा सकता है, OS को दो चीजों का ध्यान रखना पड़ता है:
- यह सॉफ़्टवेयर हमेशा तब तक चलता है जब तक उपयोगकर्ता इसे निरस्त नहीं कर देता, अर्थात इसे ऑटो-एबॉर्ट नहीं करना चाहिए क्योंकि OS मेमोरी से बाहर चला गया है।
- उपरोक्त गतिविधि, सॉफ्टवेअर चलाने के लिए सम्मानजनक प्रदर्शन बनाए रखते हुए।
अब मुख्य सवाल यह है कि स्मृति को कैसे प्रबंधित किया जा रहा है। क्या वास्तव में नियंत्रित करता है, जहां मेमोरी में किसी दिए गए सॉफ़्टवेयर से संबंधित डेटा रहता है?
संभव समाधान 1 : व्यक्तिगत सॉफ्टवेयर्स को स्पष्ट रूप से उस मेमोरी पते को निर्दिष्ट करने दें जो वे डिवाइस में उपयोग करेंगे। मान लीजिए फ़ोटोशॉप घोषणा करता है कि यह हमेशा स्मृति से लेकर पतों का उपयोग करेंगे 0करने के लिए 1023(बाइट्स की एक रेखीय सरणी के रूप में स्मृति की कल्पना है, तो पहले बाइट स्थान पर है 0, 1024वें बाइट स्थान पर है 1023) - यानी कब्जे 1 GBस्मृति। इसी तरह, वीएलसी घोषणा करता है कि यह स्मृति सीमा को घेरता है 1244करने के लिए 1876, आदि
लाभ:
- प्रत्येक एप्लिकेशन को एक मेमोरी स्लॉट प्री-असाइन किया जाता है, इसलिए जब इसे स्थापित और निष्पादित किया जाता है, तो यह उस मेमोरी क्षेत्र में अपना डेटा संग्रहीत करता है, और सब कुछ ठीक है।
नुकसान:
यह पैमाना नहीं है। सैद्धांतिक रूप से, किसी एप्लिकेशन को स्मृति की एक बड़ी मात्रा की आवश्यकता हो सकती है जब वह वास्तव में भारी-भारी कुछ कर रहा हो। इसलिए यह सुनिश्चित करने के लिए कि यह कभी भी मेमोरी से बाहर न जाए, इसके लिए आवंटित मेमोरी एरिया हमेशा मेमोरी की मात्रा के बराबर या उससे अधिक होना चाहिए। क्या होगा यदि एक सॉफ्टवेयर, जिसकी अधिकतम सैद्धांतिक स्मृति उपयोग है 2 GB(इसलिए 2 GBरैम से मेमोरी आवंटन की आवश्यकता होती है ), केवल 1 GBमेमोरी वाले मशीन में स्थापित किया गया है ? क्या सॉफ्टवेयर को केवल स्टार्टअप पर गर्भपात करना चाहिए, यह कहते हुए कि उपलब्ध रैम की तुलना में कम है 2 GB? या इसे जारी रखना चाहिए, और जिस क्षण की मेमोरी आवश्यक है 2 GB, वह अधिक है , बस गर्भपात करें और इस संदेश के साथ जमानत करें कि पर्याप्त मेमोरी उपलब्ध नहीं है?
मेमोरी मैनबलिंग को रोकना संभव नहीं है। वहाँ लाखों सॉफ्टवेयर्स हैं, भले ही उनमें से प्रत्येक को केवल 1 kBमेमोरी आवंटित की गई हो , कुल आवश्यक मेमोरी अधिक हो जाएगी 16 GB, जो कि अधिकांश उपकरणों की पेशकश से अधिक है। फिर, विभिन्न सॉफ्टवेयर्स को मेमोरी स्लॉट कैसे आवंटित किए जा सकते हैं जो एक-दूसरे के क्षेत्रों का अतिक्रमण नहीं करते हैं? सबसे पहले, कोई केंद्रीकृत सॉफ़्टवेयर बाज़ार नहीं है जो यह विनियमित कर सकता है कि जब एक नया सॉफ़्टवेयर जारी किया जा रहा है, तो उसे इस अभी तक निर्जन क्षेत्र से खुद को इतना मेमोरी असाइन करना होगा, और दूसरी बात, यदि थे भी, तो ऐसा करना संभव नहीं है क्योंकि सं। सॉफ्टवेयर के लिए व्यावहारिक रूप से अनंत है (इस प्रकार उन सभी को समायोजित करने के लिए अनंत स्मृति की आवश्यकता होती है), और किसी भी उपकरण पर उपलब्ध कुल रैम की आवश्यकता के एक अंश को भी समायोजित करने के लिए पर्याप्त नहीं है, इस प्रकार एक सॉफ्टवेयर की मेमोरी सीमा के अतिक्रमण को अपरिहार्य बना देता है उस पर। तो क्या होता है जब फ़ोटोशॉप को स्मृति स्थानों 1को सौंपा जाता है 1023और वीएलसी को सौंपा 1000जाता है 1676? यदि फ़ोटोशॉप स्थान पर कुछ डेटा संग्रहीत करता है 1008, तो VLC उसे अपने डेटा और बाद में फ़ोटोशॉप से अधिलेखित कर देता हैयह सोच कर पहुँचता है कि यह वही डेटा है जिसे पहले वहाँ संग्रहीत किया गया था? जैसा कि आप कल्पना कर सकते हैं, बुरी चीजें होंगी।
तो स्पष्ट रूप से, जैसा कि आप देख सकते हैं, यह विचार बल्कि भोला है।
संभव समाधान 2 : आइए एक और योजना का प्रयास करें - जहां ओएस मेमोरी प्रबंधन का अधिकांश हिस्सा करेगा। सॉफ्टवेयर्स, जब भी उन्हें किसी मेमोरी की आवश्यकता होती है, तो वे केवल ओएस का अनुरोध करेंगे, और ओएस तदनुसार समायोजित करेगा। Say OS यह सुनिश्चित करता है कि जब भी कोई नई प्रक्रिया मेमोरी के लिए अनुरोध कर रही है, तो यह मेमोरी को सबसे कम बाइट पते से आवंटित करेगा (जैसा कि पहले कहा गया था, रैम को बाइट्स के रैखिक सरणी के रूप में कल्पना की जा सकती है, इसलिए 4 GBरैम के लिए, पते एक के लिए सीमा होते हैं) से बाइट 0के लिए2^32-1) यदि यह प्रक्रिया शुरू हो रही है, अन्यथा यदि यह मेमोरी चलाने का अनुरोध करने वाली प्रक्रिया है, तो यह अंतिम मेमोरी लोकेशन से आबंटित होगी जहां वह प्रक्रिया अभी भी रहती है। चूंकि सॉफ्टवेयर्स यह पता लगाए बिना कि वास्तविक मेमोरी एड्रेस क्या है, जहां डेटा संग्रहीत किया जा रहा है, ओएस का मानचित्रण, प्रति सॉफ्टवेयर, वास्तविक भौतिक पते के लिए सॉफ्टवेयर द्वारा उत्सर्जित पते के प्रति बनाए रखना होगा। यह दो कारणों में से एक है जिसे हम इस अवधारणा को कहते Virtual Memoryहैं। सॉफ्टवेअर वास्तविक मेमोरी पते के बारे में परवाह नहीं कर रहे हैं, जहां उनका डेटा संग्रहीत हो रहा है, वे बस मक्खी पर पते थूकते हैं, और ओएस इसे फिट करने और इसे खोजने के लिए सही स्थान पाता है। बाद में यदि आवश्यक हो)।
कहो कि डिवाइस अभी चालू किया गया है, ओएस अभी लॉन्च हुआ है, अभी कोई अन्य प्रक्रिया नहीं चल रही है (ओएस की अनदेखी, जो एक प्रक्रिया भी है!), और आप वीएलसी लॉन्च करने का निर्णय लेते हैं । इसलिए वीएलसी को सबसे कम बाइट पते से रैम का एक हिस्सा आवंटित किया जाता है। अच्छा। अब जब वीडियो चल रहा है, तो आपको कुछ वेबपेज देखने के लिए अपना ब्राउज़र शुरू करना होगा। फिर आपको कुछ पाठ को लिखने के लिए नोटपैड लॉन्च करने की आवश्यकता है । और फिर ग्रहण कुछ कोडिंग करने के लिए .. बहुत जल्द ही आपकी स्मृति का 4 GBउपयोग किया जाता है, और RAM इस तरह दिखता है:
समस्या 1: अब आप किसी अन्य प्रक्रिया को शुरू नहीं कर सकते, क्योंकि सभी रैम का उपयोग किया जाता है। इस प्रकार कार्यक्रमों को अधिकतम स्मृति को ध्यान में रखते हुए लिखा जाना चाहिए (व्यावहारिक रूप से कम भी उपलब्ध होगा, क्योंकि अन्य सॉफ्टवेयर्स समानांतर रूप से भी चल रहे होंगे!)। दूसरे शब्दों में, आप अपने ramshackle 1 GBपीसी में एक उच्च मेमोरी खपत वाला ऐप नहीं चला सकते हैं ।
ठीक है, इसलिए अब आप तय करते हैं कि अब आपको एक्लिप्स और क्रोम को खुला रखने की आवश्यकता नहीं है , आप उन्हें कुछ मेमोरी खाली करने के लिए बंद कर देते हैं। उन प्रक्रियाओं द्वारा RAM में व्याप्त स्थान OS द्वारा पुनः प्राप्त किया जाता है, और यह अब इस तरह दिखता है:
मान लीजिए कि इन दोनों को बंद करने से 700 MBअंतरिक्ष खाली हो जाता है - ( 400+ 300) एमबी। अब आपको ओपेरा लॉन्च करने की आवश्यकता है , जो 450 MBजगह लेगा । ठीक है, आपके पास 450 MBकुल में उपलब्ध जगह से अधिक है , लेकिन ... यह सन्निहित नहीं है, इसे अलग-अलग विखंडू में विभाजित किया गया है, जिनमें से कोई भी फिट होने के लिए पर्याप्त बड़ा नहीं है 450 MB। तो आप एक शानदार विचार पर चलते हैं, चलो नीचे दिए गए सभी प्रक्रियाओं को जितना संभव हो उतना ऊपर ले जाएं, जो 700 MBखाली स्थान को एक चंक में सबसे नीचे छोड़ देगा । यह कहा जाता हैcompaction। महान, इसके अलावा ... सभी प्रक्रियाएं जो वहां चल रही हैं। उन्हें स्थानांतरित करने का मतलब होगा कि उनकी सभी सामग्रियों का पता चलना (याद रखें, OS वास्तविक मेमोरी पते के लिए सॉफ़्टवेयर द्वारा मेमोरी स्पैट की मैपिंग को बनाए रखता है। कल्पना करें कि सॉफ़्टवेयर ने 45डेटा के साथ एक पते को थूक दिया था 123, और ओएस ने इसे स्थान पर संग्रहीत किया था। 2012और मैप में एक प्रविष्टि बनाई, मैपिंग 45करने के लिए 2012। यदि सॉफ़्टवेयर को अब मेमोरी में स्थानांतरित किया जाता है, तो जो स्थान पर उपयोग किया जाता है वह 2012अब नहीं होगा 2012, लेकिन एक नए स्थान पर, और ओएस को मैप के अनुसार मैप को अपडेट 45करना होगा नया पता, ताकि सॉफ़्टवेयर को अपेक्षित डेटा मिल सके ( 123जब यह मेमोरी लोकेशन के लिए प्रश्न करता है 45। जहाँ तक सॉफ़्टवेयर का संबंध है, यह सभी जानते हैं कि यह पता है।45डेटा शामिल हैं 123!)। एक ऐसी प्रक्रिया की कल्पना करें जो एक स्थानीय चर का संदर्भ दे रही है i। जब तक इसे फिर से एक्सेस किया जाता है, तब तक इसका पता बदल जाता है, और इसे कोई और नहीं खोज पाएगा। वही सभी कार्यों, वस्तुओं, चरों के लिए धारण करेगा, मूल रूप से हर चीज का एक पता होता है, और एक प्रक्रिया को स्थानांतरित करने का मतलब उन सभी के पते को बदलना होगा। जो हमें ले जाता है:
समस्या 2: आप एक प्रक्रिया को स्थानांतरित नहीं कर सकते। उस प्रक्रिया के भीतर सभी चर, फ़ंक्शन और ऑब्जेक्ट के मानों में संकलित के दौरान कंपाइलर द्वारा स्पैट आउट के रूप में हार्डकोड किए गए मान होते हैं, यह प्रक्रिया उनके जीवनकाल के दौरान एक ही स्थान पर होने पर निर्भर करती है, और उन्हें बदलना महंगा है। परिणामस्वरूप, holesजब वे बाहर निकलते हैं तो प्रक्रियाएं बड़े " " पीछे रह जाती हैं । इसे कहते हैं
External Fragmentation।
ठीक। मान लीजिए किसी तरह, कुछ चमत्कारी तरीके से, आप प्रक्रियाओं को ऊपर ले जाने का प्रबंधन करते हैं। अब 700 MBसबसे नीचे खाली जगह है:
ओपेरा नीचे की तरफ आसानी से फिट बैठता है। अब आपका RAM इस तरह दिखता है:
अच्छा। सब कुछ ठीक लग रहा है। हालाँकि, बहुत जगह नहीं बची है, और अब आपको फिर से क्रोम , एक ज्ञात मेमोरी-हॉग लॉन्च करने की आवश्यकता है ! इसे शुरू करने के लिए बहुत सारी मेमोरी की आवश्यकता होती है, और आपके पास शायद ही कोई बचा हो ... सिवाय इसके कि .. अब आप ध्यान दें कि कुछ प्रक्रियाएँ, जो शुरू में बड़ी जगह घेर रही थीं, अब उन्हें ज़्यादा जगह की ज़रूरत नहीं है। हो सकता है कि आपने वीएलसी में अपना वीडियो बंद कर दिया हो , इसलिए यह अभी भी कुछ स्थान पर कब्जा कर रहा है, लेकिन उच्च रिज़ॉल्यूशन वीडियो को चलाने के दौरान जितना आवश्यक है उतना नहीं। इसी तरह नोटपैड और फोटोज के लिए । आपकी RAM अब इस तरह दिखती है:
Holes, एक बार फिर! एक वर्ग को वापस! सिवाय इसके, पहले, छेद प्रक्रियाओं को समाप्त करने के कारण हुए, अब यह पहले की तुलना में कम जगह की आवश्यकता वाली प्रक्रियाओं के कारण है! और आपको फिर से वही समस्या है, holesसंयुक्त की आवश्यकता से अधिक जगह मिलती है, लेकिन वे चारों ओर बिखरे हुए हैं, अलगाव में बहुत अधिक उपयोग नहीं है। तो आपको उन प्रक्रियाओं को फिर से स्थानांतरित करना होगा, एक महंगा ऑपरेशन, और उस पर एक बहुत लगातार, चूंकि प्रक्रियाएं अक्सर उनके जीवनकाल में आकार में कम हो जाएंगी।
समस्या 3: प्रक्रियाएं, उनके जीवनकाल में, अप्रयुक्त स्थान को पीछे छोड़ते हुए, आकार में कमी कर सकती हैं, जिन्हें यदि उपयोग करने की आवश्यकता होती है, तो उन्हें कई प्रक्रियाओं को चलाने के महंगे संचालन की आवश्यकता होगी। इसे कहते हैं
Internal Fragmentation।
ठीक है, तो अब, आपका ओएस आवश्यक कार्य करता है, प्रक्रियाओं को इधर-उधर करता है और क्रोम शुरू करता है और कुछ समय बाद, आपकी रैम इस तरह दिखती है:
ठंडा। अब मान लीजिए कि आप वीएलसी में अवतार देखना फिर से शुरू करते हैं । इसकी मेमोरी की आवश्यकता पूरी हो जाएगी! लेकिन ... इसके बढ़ने के लिए कोई जगह नहीं बची है, क्योंकि नोटपैड अपने निचले हिस्से पर आ गया है। इसलिए, जब तक VLC को पर्याप्त स्थान नहीं मिल जाता, तब तक सभी प्रक्रियाओं को नीचे ले जाना होगा !
समस्या 4: यदि प्रक्रियाओं को बढ़ने की आवश्यकता है, तो यह बहुत महंगा ऑपरेशन होगा
ठीक। अब मान लीजिए, तस्वीरें एक बाहरी हार्ड डिस्क से कुछ तस्वीरें लोड करने के लिए इस्तेमाल किया जा रहा है। हार्ड-डिस्क एक्सेस करना आपको डिस्क के caches और RAM के दायरे से ले जाता है, जो परिमाण के आदेश द्वारा धीमा है। दर्दनाक रूप से, अपरिवर्तनीय रूप से, पारदर्शी रूप से धीमा। यह एक I / O ऑपरेशन है, जिसका अर्थ है कि यह सीपीयू बाउंड नहीं है (यह बल्कि बिल्कुल विपरीत है), जिसका मतलब है कि इसे अभी रैम पर कब्जा करने की आवश्यकता नहीं है। हालांकि, यह अभी भी हठीली रैम पर काबिज है। यदि आप इस बीच फ़ायरफ़ॉक्स लॉन्च करना चाहते हैं , तो आप नहीं कर सकते, क्योंकि वहाँ बहुत अधिक मेमोरी उपलब्ध नहीं है, जबकि अगर फ़ोटो को उसकी I / O बाध्य गतिविधि की अवधि के लिए मेमोरी से बाहर निकाल दिया जाता, तो यह बहुत सारी मेमोरी को मुक्त कर देता; (महंगे) संघनन के बाद, फ़ायरफ़ॉक्स फिटिंग के बाद।
समस्या 5: I / O बाध्य नौकरियां RAM पर कब्जा करती रहती हैं, जिससे RAM का उपयोग कम होता है, जिसका उपयोग इस बीच CPU बाध्य नौकरियों द्वारा किया जा सकता था।
इसलिए, जैसा कि हम देख सकते हैं, वर्चुअल मेमोरी के दृष्टिकोण से भी हमें इतनी समस्याएं हैं।
इन समस्याओं से निपटने के लिए दो दृष्टिकोण हैं - pagingऔर segmentation। आइए चर्चा करते हैं paging। इस दृष्टिकोण में, एक प्रक्रिया के वर्चुअल एड्रेस स्पेस को चंक्स में भौतिक मेमोरी में मैप किया जाता है - जिसे कहा जाता है pages। एक विशिष्ट pageआकार है 4 kB। मानचित्रण को कुछ के द्वारा बनाए रखा जाता है page table, जिसे एक वर्चुअल एड्रेस दिया जाता है , अब हमें केवल यह पता लगाना है pageकि पता किसका है, फिर उससे वास्तविक भौतिक मेमोरी में page tableसंबंधित स्थान pageज्ञात करें (जैसा कि जाना जाता है frame), और दिया गया वर्चुअल पते की ऑफ़सेट, साथ pageही साथ के लिए समान pageहै frame, वास्तविक ऑफ़सेट को उस ऑफ़सेट से जोड़कर पता करें, जिस पते पर लौटा है page table। उदाहरण के लिए:
बाईं ओर एक प्रक्रिया का आभासी पता स्थान है। बता दें वर्चुअल एड्रेस स्पेस में 40 यूनिट मेमोरी की जरूरत होती है। यदि भौतिक पता स्थान (दाईं ओर) में 40 इकाइयों की मेमोरी होती है, तो बाईं ओर से सभी स्थानों को दाईं ओर स्थान पर मैप करना संभव होता, और हम बहुत खुश होते। लेकिन जैसा कि दुर्भाग्य होता है, न केवल भौतिक स्मृति कम होती है (24 यहाँ) मेमोरी इकाइयाँ उपलब्ध हैं, इसे कई प्रक्रियाओं के बीच भी साझा किया जाना है! ठीक है, देखते हैं कि हम इसे कैसे बनाते हैं।
जब प्रक्रिया शुरू होती है, तो कहें कि स्थान के लिए मेमोरी एक्सेस अनुरोध किया 35जाता है। यहां पृष्ठ का आकार है 8(प्रत्येक pageमें 8स्थान शामिल हैं , स्थानों का संपूर्ण आभासी पता 40स्थान इस प्रकार 5पृष्ठ हैं)। तो यह स्थान पृष्ठ संख्या के अंतर्गत आता है। 4( 35/8)। इसके भीतर page, इस स्थान की ऑफ़सेट 3( 35%8) है। तो इस स्थान को tuple (pageIndex, offset)= द्वारा निर्दिष्ट किया जा सकता है (4,3)। यह सिर्फ शुरुआत है, इसलिए प्रक्रिया का कोई भी हिस्सा वास्तविक भौतिक स्मृति में संग्रहीत नहीं है। तो page table, जो दाईं ओर वास्तविक पृष्ठों पर बाईं ओर पृष्ठों की मैपिंग बनाए रखता है (जहां उन्हें कहा जाता हैframes) वर्तमान में खाली है। इसलिए OS CPU को छोड़ देता है, डिवाइस ड्राइवर को डिस्क तक पहुंचने देता है और पेज नं। 4इस प्रक्रिया (डिस्क जिसका पतों से लेकर पर कार्यक्रम से मूल रूप से एक स्मृति हिस्सा के लिए 32करने के लिए 39)। जब यह आता है, तो ओएस पेज को रैम में कहीं आवंटित करता है, पहले फ्रेम को ही कहता है, और page tableइस प्रक्रिया के लिए उस पेज के 4नक्शे को 0रैम में फ्रेम करने पर ध्यान देता है । अब डेटा अंत में भौतिक मेमोरी में है। ओएस फिर से ट्यूपल के लिए पेज टेबल पर सवाल करता है (4,3), और इस बार, पेज टेबल का कहना है कि पेज 4पहले से ही 0रैम में फ्रेम करने के लिए मैप किया गया है। इसलिए OS बस 0RAM में th फ्रेम में जाता है , डेटा को 3उस फ्रेम में ऑफ़सेट तक पहुँचाता है (इसे समझने के लिए कुछ समय लें।)page, जिसे डिस्क से लाया गया था, को स्थानांतरित कर दिया गया है frame। तो जो कुछ भी एक पृष्ठ में एक व्यक्तिगत मेमोरी लोकेशन की ऑफसेट था, वह फ्रेम में भी समान होगा, क्योंकि page/ के भीतर frame, मेमोरी यूनिट अभी भी अपेक्षाकृत उसी स्थान पर रहती है!), और डेटा लौटाता है। क्योंकि डेटा को पहले क्वेरी में मेमोरी में नहीं पाया गया था, बल्कि इसे डिस्क से मेमोरी में लोड करने के लिए लाया जाना था, यह एक मिस का गठन करता है ।
ठीक। अब मान लीजिए, स्थान के लिए एक मेमोरी एक्सेस 28बनाई गई है। यह करने के लिए फोड़ा (3,4)। Page tableअभी केवल एक प्रविष्टि है, मानचित्रण पृष्ठ 4को फ्रेम करने के लिए 0। तो यह फिर से एक मिस है , प्रक्रिया सीपीयू को छोड़ देती है, डिवाइस ड्राइवर डिस्क से पृष्ठ को प्राप्त करता है, प्रक्रिया फिर से सीपीयू का नियंत्रण प्राप्त करती है, और इसका page tableअद्यतन किया जाता है। अब कहें कि पेज 3को 1RAM में फ्रेम करने के लिए मैप किया गया है। तो (3,4)बन जाता है (1,4), और रैम में उस स्थान का डेटा वापस आ जाता है। अच्छा। इस तरह, मान लीजिए कि अगली मेमोरी एक्सेस लोकेशन के लिए है 8, जिसका अनुवाद है (1,0)। पृष्ठ 1अभी तक मेमोरी में नहीं है, वही प्रक्रिया दोहराई जाती है, और इसे pageफ्रेम में आवंटित किया जाता है2राम में। अब रैम-प्रोसेस मैपिंग ऊपर की तस्वीर जैसा दिखता है। इस समय, रैम, जिसमें केवल 24 यूनिट मेमोरी उपलब्ध थी, को भरा जाता है। मान लीजिए कि इस प्रक्रिया के लिए अगला मेमोरी एक्सेस अनुरोध पते से है 30। यह मैप करता है (3,6), और page tableकहता है कि पेज 3रैम में है, और यह मैप करने के लिए मैप करता है 1। वाह! इसलिए डेटा को RAM स्थान से प्राप्त किया जाता है (1,6), और वापस आ जाता है। यह एक हिट का गठन करता है , क्योंकि आवश्यक डेटा सीधे रैम से प्राप्त किया जा सकता है, इस प्रकार बहुत तेज हो सकता है। इसी तरह, अगले कुछ पहुंच के अनुरोध, स्थानों के लिए कहते हैं 11, 32, 26, 27सब कर रहे हैं हिट , यानी प्रक्रिया द्वारा अनुरोध डेटा कहीं और देखने के जरूरत के बिना रैम में सीधे पाया जाता है।
अब मान लें कि स्थान के लिए मेमोरी एक्सेस अनुरोध 3आता है। यह इस प्रक्रिया के लिए (0,3), और page tableवर्तमान में 3 प्रविष्टियों के लिए, पृष्ठों के लिए अनुवाद करता है 1, 3और 4कहता है कि यह पृष्ठ स्मृति में नहीं है। पिछले मामलों की तरह, यह डिस्क से लिया गया है, हालांकि, पिछले मामलों के विपरीत, रैम भरा हुआ है! तो अब क्या करना है? यहां आभासी स्मृति की सुंदरता निहित है, रैम से एक फ्रेम को निकाला गया है! (विभिन्न कारक नियंत्रित करते हैं कि किस फ्रेम को बेदखल किया जाना है। यह LRUआधारित हो सकता है, जहां एक प्रक्रिया के लिए हाल ही में एक्सेस की गई फ्रेम को बेदखल किया जाना है। यह first-come-first-evictedआधार हो सकता है, जहां फ्रेम जो सबसे लंबे समय पहले आवंटित किया गया है, वह बेदखल है, आदि। ।) तो कुछ फ्रेम बेदखल है। फ़्रेम 1 कहो (बस यादृच्छिक रूप से इसे चुनना)। हालाँकि, frameकुछ के लिए मैप किया गया हैpage! (वर्तमान में, यह 3हमारे एक और केवल एक प्रक्रिया के पेज टेबल द्वारा मैप किया जाता है)। तो उस प्रक्रिया को इस दुखद खबर के बारे में बताया जाना चाहिए frame, जो कि आप में से दुर्भाग्यपूर्ण है, जिसे दूसरे के लिए जगह बनाने के लिए रैम से निकाला जाना है pages। प्रक्रिया को यह सुनिश्चित करना है कि यह page tableइस जानकारी के साथ इसे अपडेट करता है, अर्थात्, उस पृष्ठ-फ़्रेम जोड़ी के लिए प्रविष्टि को हटाता है, ताकि अगली बार उसके लिए एक अनुरोध किया जाए page, यह प्रक्रिया को सही बताता है कि यह pageअब मेमोरी में नहीं है , और डिस्क से लाया जाना है। अच्छा। इसलिए फ़्रेम 1को निकाल दिया जाता है, पेज 0को रैम में लाया जाता है और वहां रखा 3जाता है, और पेज के लिए प्रविष्टि को हटा दिया जाता है, और पेज 0मैपिंग द्वारा उसी फ्रेम में बदल दिया जाता है1। तो अब हमारी मैपिंग इस तरह दिखती है ( frameदाईं ओर दूसरे हिस्से में रंग बदलने पर ध्यान दें ):
देखा क्या हुआ बस? प्रक्रिया को विकसित होना था, इसके लिए उपलब्ध रैम की तुलना में अधिक स्थान की आवश्यकता थी, लेकिन हमारे पहले के परिदृश्य के विपरीत जहां रैम में प्रत्येक प्रक्रिया को एक बढ़ती प्रक्रिया को समायोजित करने के लिए आगे बढ़ना था, यहां यह सिर्फ एक pageप्रतिस्थापन द्वारा हुआ ! यह इस तथ्य से संभव बनाया गया था कि किसी प्रक्रिया के लिए मेमोरी को अब सन्निहित होने की आवश्यकता नहीं है, यह विखंडू में विभिन्न स्थानों पर निवास कर सकती है, ओएस जानकारी को उसी स्थान पर रखता है जहां वे हैं, और जब आवश्यक हो, तो उन्हें उचित रूप से समझा जाता है। नोट: आप सोच रहे होंगे, हह, क्या होगा अगर ज्यादातर बार यह एक है miss, और डेटा को लगातार डिस्क से मेमोरी में लोड करना पड़ता है? हां, सैद्धांतिक रूप से, यह संभव है, लेकिन अधिकांश संकलक इस तरह से डिज़ाइन किए गए हैं जो निम्नानुसार हैंlocality of reference, अर्थात यदि कुछ मेमोरी लोकेशन के डेटा का उपयोग किया जाता है, तो आवश्यक अगला डेटा कहीं बहुत निकट स्थित होगा, शायद उसी से page, pageजो अभी मेमोरी में लोड किया गया था। नतीजतन, अगली याद काफी समय के बाद होगी, आने वाली स्मृति आवश्यकताओं में से अधिकांश बस द्वारा लाए गए पृष्ठ या पहले से ही स्मृति में पहले से उपयोग किए गए पृष्ठों से मिलेंगे। ठीक वही सिद्धांत हमें pageतर्क के साथ कम से कम हाल ही में उपयोग किए गए बेदखल करने की अनुमति देता है , जो कि थोड़ी देर में उपयोग नहीं किया गया है, थोड़ी देर में भी इस्तेमाल होने की संभावना नहीं है। हालांकि, यह हमेशा ऐसा नहीं होता है, और असाधारण मामलों में, हां, प्रदर्शन में नुकसान हो सकता है। इसके बारे में बाद में।
समस्या 4 का समाधान: प्रक्रियाएं अब आसानी से बढ़ सकती हैं, अगर अंतरिक्ष की समस्या का सामना करना पड़ता है, तो इसके लिए pageकिसी भी अन्य प्रक्रिया को आगे बढ़ाए बिना एक सरल प्रतिस्थापन करना आवश्यक है ।
समस्या 1 का समाधान: एक प्रक्रिया असीमित मेमोरी तक पहुंच सकती है। जब उपलब्ध से अधिक मेमोरी की आवश्यकता होती है, तो डिस्क का बैकअप के रूप में उपयोग किया जाता है, आवश्यक नए डेटा को डिस्क से मेमोरी में लोड किया जाता है, और हाल ही में उपयोग किए गए डेटा frame(या page) को डिस्क में ले जाया जाता है। यह असीम रूप से चल सकता है, और चूंकि डिस्क स्थान सस्ता है और लगभग असीमित है, यह असीमित स्मृति का भ्रम देता है। नाम का एक और कारण Virtual Memory, यह आपको स्मृति का भ्रम देता है जो वास्तव में उपलब्ध नहीं है!
ठंडा। पहले हम एक समस्या का सामना कर रहे थे, जहां भले ही एक प्रक्रिया आकार में कम हो जाती है, खाली जगह को अन्य प्रक्रियाओं द्वारा पुनः प्राप्त किया जाना मुश्किल है (क्योंकि इसके लिए महंगा संघनन की आवश्यकता होगी)। अब यह आसान है, जब एक प्रक्रिया आकार में छोटी हो जाती pagesहै, तो इसके कई उपयोग नहीं किए जाते हैं, इसलिए जब अन्य प्रक्रियाओं को अधिक मेमोरी की आवश्यकता होती है, तो एक साधारण LRUआधारित बेदखली स्वचालित रूप pagesसे रैम से कम उपयोग करने वालों को दर्शाती है , और उन्हें नए पृष्ठों से बदल देती है अन्य प्रक्रियाएं (और निश्चित page tablesरूप से उन सभी प्रक्रियाओं के साथ-साथ मूल प्रक्रिया को भी अपडेट करने की आवश्यकता है जो अब कम जगह की आवश्यकता होती है), इन सभी को बिना किसी महंगा संघनन ऑपरेशन के!
समस्या 3 का समाधान: जब भी प्रक्रियाएं आकार framesमें कम होती हैं, तो रैम में इसका उपयोग कम होता है, इसलिए एक साधारण LRUआधारित निष्कासन उन पृष्ठों को बाहर निकाल सकता है और उन्हें pagesनई प्रक्रियाओं द्वारा आवश्यक रूप से प्रतिस्थापित कर सकता है, इस प्रकार Internal Fragmentationबिना आवश्यकता के बचता है compaction।
समस्या 2 के रूप में, इसे समझने के लिए एक क्षण ले लो, परिदृश्य खुद पूरी तरह से हटा दिया जाता है! नई प्रक्रिया को समायोजित करने के लिए एक प्रक्रिया को स्थानांतरित करने की आवश्यकता नहीं है, क्योंकि अब पूरी प्रक्रिया को एक बार में फिट होने की आवश्यकता नहीं है, केवल इसके कुछ पृष्ठों को तदर्थ को फिट करने की आवश्यकता है, जो कि framesरैम से बेदखल होने से होता है । सब कुछ इकाइयों में होता है pages, इस प्रकार holeअब कोई अवधारणा नहीं है , और इसलिए कुछ भी हिलने का सवाल नहीं है! pagesइस नई आवश्यकता के कारण 10 को स्थानांतरित करना पड़ा, जिनमें से हजारों pagesअछूते रह गए हैं। जबकि, पहले, सभी प्रक्रियाओं (उनमें से प्रत्येक बिट) को स्थानांतरित करना पड़ा!
समस्या 2 का समाधान: एक नई प्रक्रिया को समायोजित करने के लिए, आवश्यक प्रक्रियाओं के केवल कम हाल ही में उपयोग किए गए भागों से डेटा को निकाला जाना चाहिए, और इसे निश्चित आकार की इकाइयों में कहा जाता है pages। इस प्रकार इस प्रणाली के साथ holeया इसकी कोई संभावना नहीं External Fragmentationहै।
अब जब प्रक्रिया को कुछ I / O ऑपरेशन करने की आवश्यकता होती है, तो यह CPU को आसानी से त्याग सकता है! ओएस केवल pagesरैम से अपने सभी को दिखाता है (शायद इसे कुछ कैश में संग्रहीत करता है) जबकि नई प्रक्रियाएं इस बीच में रैम पर कब्जा कर लेती हैं। जब I / O ऑपरेशन किया जाता है, तो OS बस उन pagesRAM को पुनर्स्थापित करता है (बेशक pagesकुछ अन्य प्रक्रियाओं से बदलकर , उन लोगों से हो सकता है जो मूल प्रक्रिया को बदल देते हैं, या कुछ ऐसे हो सकते हैं, जिन्हें स्वयं I / करने की आवश्यकता होती है हे अब, और इसलिए स्मृति को त्याग सकते हैं!)
समस्या 5 का समाधान: जब कोई प्रक्रिया I / O संचालन कर रही होती है, तो वह आसानी से RAM उपयोग छोड़ सकती है, जिसका उपयोग अन्य प्रक्रियाओं द्वारा किया जा सकता है। इससे रैम का उचित उपयोग होता है।
और हां, अब कोई भी प्रक्रिया सीधे रैम तक नहीं पहुंच पा रही है। प्रत्येक प्रक्रिया एक वर्चुअल मेमोरी लोकेशन तक पहुंच रही है, जिसे एक भौतिक रैम पते पर मैप किया जाता है और page-tableउस प्रक्रिया को बनाए रखा जाता है। मैपिंग ओएस-समर्थित है, ओएस प्रक्रिया को यह जानने देता है कि कौन सा फ्रेम खाली है ताकि प्रक्रिया के लिए एक नया पेज वहां फिट किया जा सके। चूँकि यह मेमोरी आवंटन OS द्वारा स्वयं की देखरेख की जाती है, इसलिए यह आसानी से सुनिश्चित कर सकता है कि कोई भी प्रक्रिया रैम से केवल खाली फ्रेम आवंटित करके, या रैम में किसी अन्य प्रक्रिया की सामग्री का अतिक्रमण करके किसी अन्य प्रक्रिया की सामग्री का अतिक्रमण नहीं करती है, इस प्रक्रिया के लिए संवाद करें इसे अद्यतन करने के लिए page-table।
मूल समस्या का समाधान: किसी अन्य प्रक्रिया की सामग्री तक पहुँचने वाली प्रक्रिया की कोई संभावना नहीं है, क्योंकि संपूर्ण आवंटन को ओएस द्वारा ही प्रबंधित किया जाता है, और प्रत्येक प्रक्रिया अपने सैंडबॉक्स वाले वर्चुअल एड्रेस स्पेस में चलती है।
तो paging(अन्य तकनीकों के बीच), आभासी स्मृति के साथ संयोजन के रूप में, आज की सॉफ्टवेअर OS-es पर चलने वाली शक्तियां हैं! यह सॉफ्टवेयर डेवलपर को इस बात की चिंता से मुक्त करता है कि उपयोगकर्ता के डिवाइस पर कितनी मेमोरी उपलब्ध है, जहां डेटा को स्टोर करना है, अन्य प्रक्रियाओं को अपने सॉफ़्टवेयर के डेटा को दूषित करने से कैसे रोकना है, आदि। हालांकि, यह निश्चित रूप से पूर्ण प्रमाण नहीं है। दोष हैं:
Pagingअंत में, उपयोगकर्ता को बैकअप के रूप में डिस्क का उपयोग करके अनंत स्मृति का भ्रम दे रहा है। मेमोरी में फिट होने के लिए सेकेंडरी स्टोरेज से डेटा को पुनः प्राप्त करना (कहा जाता है page swap, और रैम में वांछित पेज नहीं मिलने की घटना को कहा जाता है page fault) महंगा है क्योंकि यह एक आईओ ऑपरेशन है। यह प्रक्रिया को धीमा कर देता है। उत्तराधिकार में ऐसे कई पृष्ठ स्वैप होते हैं, और यह प्रक्रिया धीमी गति से धीमी हो जाती है। कभी अपने सॉफ़्टवेयर को ठीक और बांका चलाते देखा है, और अचानक यह इतना धीमा हो जाता है कि यह लगभग लटका रहता है, या आपको इसे फिर से चालू करने के लिए कोई विकल्प नहीं छोड़ता है? संभवतः बहुत सारे पृष्ठ स्वैप हो रहे थे, जिससे यह धीमा हो गया (कहा जाता है thrashing)।
तो वापस ओपी में आ रहा हूं,
हमें किसी प्रक्रिया को निष्पादित करने के लिए आभासी मेमोरी की आवश्यकता क्यों है? - जैसा कि उत्तर लंबाई में समझाता है, सॉफ्टवेयर्स को डिवाइस / ओएस का भ्रम देने के लिए जिसमें असीम मेमोरी होती है, ताकि किसी भी सॉफ्टवेयर, बड़े या छोटे, को चलाया जा सके, स्मृति आवंटन की चिंता किए बिना, या अन्य प्रक्रियाएं इसके डेटा को दूषित करते हुए, तब भी समानांतर में चल रहा है। यह एक अवधारणा है, जिसे विभिन्न तकनीकों के माध्यम से व्यवहार में लागू किया जाता है, जिनमें से एक, जैसा कि यहां वर्णित है, पेजिंग है । यह सेगमेंटेशन भी हो सकता है ।
बाहरी हार्ड ड्राइव से प्रक्रिया (प्रोग्राम) को निष्पादन के लिए मुख्य मेमोरी (भौतिक मेमोरी) में लाए जाने पर यह वर्चुअल मेमोरी कहां खड़ी होती है? - वर्चुअल मेमोरी प्रति se कहीं भी नहीं रहती है, यह एक अमूर्तता है, हमेशा मौजूद रहती है, जब सॉफ्टवेयर / प्रोसेस / प्रोग्राम को बूट किया जाता है, तो इसके लिए एक नया पेज टेबल बनाया जाता है, और इसमें उस पते से मैपिंग होती है, जिसके द्वारा स्पैट किया जाता है रैम में वास्तविक भौतिक पते के लिए प्रक्रिया। चूँकि प्रक्रिया से बाहर निकले पते वास्तविक पते नहीं होते हैं, एक अर्थ में, वे वास्तव में, आप क्या कह सकते हैं the virtual memory,।
वर्चुअल मेमोरी का ख्याल कौन रखता है और वर्चुअल मेमोरी का आकार क्या है? - यह ध्यान में रखा जाता है, अग्रानुक्रम में, ओएस और सॉफ्टवेयर। अपने कोड में एक फ़ंक्शन की कल्पना करें (जो अंततः संकलित और निष्पादन योग्य में बनाया गया था जिसने प्रक्रिया को जन्म दिया) जिसमें एक स्थानीय चर शामिल है - ए int i। जब कोड निष्पादित होता है, iतो फ़ंक्शन के ढेर के भीतर एक मेमोरी एड्रेस मिलता है। वह फ़ंक्शन स्वयं एक ऑब्जेक्ट के रूप में कहीं और संग्रहीत होता है। ये पते कंपाइलर जनरेट होते हैं (कंपाइलर जो आपके कोड को एक्जीक्यूटेबल में संकलित करता है) - वर्चुअल एड्रेस। जब निष्पादित iकिया जाता है , तो उस फ़ंक्शन की अवधि के लिए वास्तविक भौतिक पते में कहीं न कहीं निवास करना पड़ता है (जब तक कि यह एक स्थिर संस्करण न हो!), इसलिए OS संकलक द्वारा वर्चुअल पता जनरेट किया गया मैप करता हैiएक वास्तविक भौतिक पते में, ताकि जब भी उस फ़ंक्शन के भीतर, कुछ कोड के लिए मूल्य की आवश्यकता हो i, तो उस प्रक्रिया को वर्चुअल पते के लिए OS को क्वेरी कर सकता है, और बदले में ओएस संग्रहीत पते के लिए भौतिक पते को क्वेरी कर सकता है, और इसे वापस कर सकता है।
मान लीजिए कि यदि RAM का आकार 4GB है (यानी 2 ^ 32-1 एड्रेस स्पेस) तो वर्चुअल मेमोरी का आकार क्या है? - RAM का आकार वर्चुअल मेमोरी के आकार से संबंधित नहीं है, यह OS पर निर्भर करता है। उदाहरण के लिए, 32 बिट विंडोज पर, यह 16 TB64 बिट विंडोज पर है, यह है 256 TB। बेशक, यह डिस्क आकार द्वारा भी सीमित है, क्योंकि यह वह जगह है जहां मेमोरी का बैकअप होता है।