यह एक पुरानी पोस्ट है, हालांकि, मैं अभी भी अपने विचारों को यहां रखने की स्वतंत्रता लूंगा।
नीचे से शुरू करके, लिनक्स सबसे पहले मेमोरी को पेजों (आमतौर पर x86_64 सिस्टम पर 4K प्रति पेज) में विभाजित करेगा। इसके बाद, वर्चुअल मेमोरी बनाई जाती है, जिसका एमएमयू (मेमोरी मैनेजमेंट यूनिट) का उपयोग करके भौतिक मेमोरी के साथ मैपिंग की जाती है।
वर्चुअल मेमोरी क्षेत्र से प्रक्रियाओं को मेमोरी आवंटित की जाती है, इसलिए कृपया ध्यान दें, जब आप देखते हैं / proc / meminfo, तो आप VMalloc * को वर्चुअल मेमोरी विवरण के रूप में देखेंगे।
कहते हैं कि आपके पास स्मृति के लिए अनुरोध करने वाली एक प्रक्रिया है (जैसे कि 300MB - एक वेब ब्राउज़र)। वर्चुअल मेमोरी से इस प्रक्रिया को 300MB आवंटित किया जाएगा, हालांकि, यह आवश्यक नहीं है कि यह मेमोरी मैप्ड हो (जिसे भौतिक मेमोरी में मैप किया जाता है)। मेमोरी प्रबंधन के लिए "कॉपी पर राइट" की अवधारणा है, जिसके तहत, यदि आपकी प्रक्रियाएं वास्तव में वर्चुअल मेमोरी से आवंटित मेमोरी का उपयोग करती हैं (अर्थात यह मेमोरी पर कुछ लिखती है), तो केवल भौतिक मेमोरी में मैप किया जाता है। यह कर्नेल को एक बहु-प्रक्रिया वातावरण में ठीक से काम करने के लिए कुशलतापूर्वक सहायता करता है।
कैश क्या हैं?
प्रक्रियाओं द्वारा उपयोग की जाने वाली बहुत सी मेमोरी साझा की जाती हैं। बता दें कि ग्लिबेक लाइब्रेरी का उपयोग लगभग सभी प्रक्रियाओं द्वारा किया जाता है। मेमोरी में ग्लिबक की कई प्रतियां रखने का क्या मतलब है, जब हर प्रक्रिया एक ही मेमोरी स्थान तक पहुंच सकती है और काम कर सकती है। ऐसे अक्सर उपयोग किए जाने वाले संसाधनों को कैश में रखा जाता है ताकि जब प्रक्रिया की मांग हो, तो उन्हें उसी मेमोरी लोकेशन पर भेजा जा सके। यह प्रक्रियाओं को गति देने में मदद करता है, जैसा कि glibc (आदि।) को डिस्क से फिर से पढ़ने में समय लगता है।
प्रति शेयर की गई लाइब्रेरियों के लिए ऊपर था, रीडिंग फाइल करने के लिए भी यही सच है। यदि आप पहली बार एक बड़ी फ़ाइल (कहते हैं 100-200MB) पढ़ते हैं, तो इसमें बहुत समय लगेगा। हालाँकि, जब आप कोशिश करते हैं और फिर से वही पढ़ते हैं, तो यह तेज़ होगा। डेटा को मेमोरी में कैश किया गया था, और सभी ब्लॉकों के लिए फिर से रीड नहीं किया गया था।
बफर क्या है?
जहां तक बफर का सवाल है, जब कोई प्रक्रिया I / O फाइल करती है, तो यह डेटा को डिस्क पर लिखने के लिए कर्नेल के बफर पर निर्भर करता है। प्रक्रियाएं, कर्नेल को कार्य करने का अनुरोध करती हैं। तो, प्रक्रिया की ओर से, कर्नेल अपने "बफर" को डेटा लिखता है, और प्रक्रिया को बताता है कि लेखन किया जाता है। एक async तरीके से, कर्नेल इस डेटा को बफर में डिस्क में सिंक करता रहेगा। इस तरह, डिस्क पर डेटा सिंक करने के लिए सही समय चुनने के लिए प्रक्रियाएँ कर्नेल पर निर्भर होती हैं, और प्रक्रियाएँ आगे काम करना जारी रख सकती हैं। याद रखें, यह सामान्य I / O है जो सामान्य प्रक्रियाएं कर रही हैं। हालांकि, विशेष प्रक्रियाएं, जिन्हें यह पुष्टि करने की आवश्यकता है कि I / O वास्तव में डिस्क पर किया गया है, डिस्क पर I / O करने के लिए अन्य तंत्र का उपयोग कर सकता है। ओपनसोर्स उपयोगिताओं में से कुछ लिबियो हैं। इसके अलावा, आपकी प्रक्रियाओं के संदर्भ में खोले गए एफडी के लिए स्पष्ट सिंक को कॉल करने के तरीके हैं,
पेज दोष क्या हैं?
एक उदाहरण पर विचार करें, जब आप एक प्रक्रिया शुरू करते हैं (एक वेब ब्राउज़र कहते हैं), जिसका बाइनरी लगभग 300 एमबी है। हालाँकि, वेब ब्राउज़र बाइनरी का पूर्ण 300MB तुरंत काम करना शुरू नहीं करता है। प्रक्रिया अपने कोड में फ़ंक्शंस-टू-फ़ंक्शंस से चलती रहती है। जैसा कि पहले कहा गया है, वर्चुअल मेमोरी 300 एमबी की खपत होगी, लेकिन सभी मेमोरी को भौतिक मेमोरी में मैप नहीं किया जाता है (आरएसएस - निवासी मेमोरी कम होगी, शीर्ष आउटपुट देखें)। जब कोड निष्पादन एक बिंदु पर पहुंच जाता है, जिसके लिए मेमोरी वास्तव में भौतिक रूप से मैप नहीं की जाती है, तो एक पेज की गलती मुद्दों होगी। कर्नेल इस मेमोरी को भौतिक में मैप करेगा, मेमोरी पेज को आपकी प्रक्रिया में संबद्ध करेगा। ऐसे पृष्ठ दोष को "मामूली पृष्ठ दोष" कहा जाता है। इसी तरह, जब एक प्रक्रिया फ़ाइल I / O कर रही होती है, तो प्रमुख पृष्ठ दोष उठाए जाते हैं।
स्वैप आउट कब और क्यों होता है?
स्थिति 1:
ऊपर दिए गए विवरणों के साथ, एक परिदृश्य पर विचार करने देता है जब अच्छी मात्रा में मेमोरी मैप हो जाती है। और अब एक प्रक्रिया शुरू होती है, जिसमें स्मृति की आवश्यकता होती है। जैसा कि ऊपर चर्चा की गई है, कर्नेल में कुछ मेमोरी मैपिंग होगी। हालाँकि, मेमोरी को मैप करने के लिए पर्याप्त भौतिक रैम उपलब्ध नहीं है। अब, कर्नेल पहले कैश में दिखेगा, इसमें कुछ पुराने मेमोरी पेज होंगे जिनका उपयोग नहीं किया जा रहा है। यह उन पृष्ठों को एक अलग विभाजन (SWAP कहा जाता है) पर फ़्लश करेगा, कुछ पृष्ठों को मुक्त करेगा, और आने वाले नए अनुरोधों के लिए पृष्ठों को मुक्त करेगा। चूंकि सॉलिड-स्टेट रैम की तुलना में डिस्क लेखन बहुत धीमा है, इसलिए इस प्रक्रिया में बहुत समय लगता है, और इसलिए धीमी गति देखी जाती है।
स्थिति 2:
कहते हैं कि आपको सिस्टम में बहुत सारी मुफ्त मेमोरी उपलब्ध हैं। तब भी आप देखते हैं कि बहुत अधिक स्वैग-आउट हो रहा है। स्मृति विखंडन का एक संभावित मुद्दा हो सकता है। एक प्रक्रिया पर विचार करें, जो कर्नेल से 50MB सन्निहित स्मृति की मांग करता है। (ध्यान रखें सन्निहित)। जाहिर है, कर्नेल ने विभिन्न प्रक्रियाओं के लिए पृष्ठों को यादृच्छिक रूप से आवंटित किया होगा, और उनमें से कुछ को मुक्त कर दिया। हालांकि, जब हम सन्निहित स्मृति की मांग करते हैं, तो उसे एक ऐसे चंक की तलाश करनी होगी जो प्रक्रियाओं की मांग को पूरा करता है। यदि यह ऐसी मेमोरी प्राप्त करने में सक्षम नहीं है, तो इसे कुछ पुराने मेमोरी पेजों की अदला-बदली करनी होगी और फिर सन्निहित लोगों को आवंटित करना होगा। यहां तक कि ऐसे मामलों में SWAP बाहर होगा। कर्नेल क्रिया 2.6 और इसके बाद के संस्करण शुरू करने से ऐसी विखंडन समस्याएं काफी कम हो गई हैं। हालांकि, यदि सिस्टम लंबे समय से चल रहा है, तो ऐसी समस्याएं अभी भी आ सकती हैं।
इस उदाहरण को देखें ( vmstat आउटपुट )
2016-10-29 03:55:32 procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
2016-10-29 03:55:32 r b swpd free buff cache si so bi bo in cs us sy id wa st
2016-10-30 03:56:04 19 23 2914752 4692144 3344908 12162628 1660 1 8803 12701 4336 37487 14 7 40 38 0
2016-10-30 03:56:34 3 20 2889296 4977580 3345316 12026752 2109 2 8445 14665 4656 36294 12 7 46 34 0
2016-10-30 03:57:04 1 11 3418868 4939716 3347804 11536356 586 4744 2547 9535 3086 24450 6 3 59 33 0 <<<-----
2016-10-30 03:57:34 3 19 3456252 5449884 3348400 11489728 3291 13371 6407 17957 2997 22556 6 4 66 24 0
2016-10-30 03:58:04 7 6 4194500 5663580 3349552 10857424 2407 12240 3824 14560 2295 18237 4 2 65 29 0
2016-10-30 03:58:34 2 16 4203036 5986864 3348908 10838492 4601 16639 7219 18808 2575 21563 6 4 60 31 0
2016-10-30 03:59:04 3 14 4205652 6059196 3348760 10821448 6624 1597 9431 4357 1750 20471 6 2 60 31 0
2016-10-30 03:59:34 2 24 4206968 6053160 3348876 10777216 5221 2067 10106 7377 1731 19161 3 3 62 32 0
2016-10-30 04:00:04 0 13 4205172 6005084 3348932 10785896 6236 1609 10330 6264 1739 20348 4 2 67 26 0
2016-10-30 04:00:34 4 11 4206420 5996396 3348976 10770220 6554 1253 10382 4896 1964 42981 10 5 58 27 0
2016-10-30 04:01:04 6 4 4177176 5878852 3348988 10825840 8682 765 10126 2716 1731 32949 8 4 69 19 0
@ 2016-10-30 03:57:04, हम देखते हैं कि अभी भी अच्छी मात्रा में मुफ्त रैम उपलब्ध है। हालाँकि, तब भी स्वैप आउट हुआ। हमने इस बिंदु पर प्रक्रिया के पेड़ की जाँच की, और हमने ऐसी कोई प्रक्रिया नहीं देखी, जो इतनी अधिक मात्रा में स्मृति (मुक्त स्मृति से अधिक) की मांग करे। स्पष्ट संदेह ऊपर वर्णित 2 था। हमने ऊपर दोस्तइनफो और ज़ोनइनफो लॉग की जाँच की (इनकी जाँच करने के लिए इको मी> / प्रिक / sysrq-ट्रिगर का उपयोग करें, आउटपुट syslogs में जाता है)।
हमारी एक सामान्य प्रणाली के लिए, ज़ोन जानकारी की तुलना यह इस प्रकार है। और कैश / फ्री / कम मेम के लिए रेखांकन भी नीचे उल्लेखित है
जानकारी को देखते हुए, यह स्पष्ट है कि नोड 0 और नोड 1 सामान्य में मेमोरी विखंडन है (नोड यह NUMA आधारित मशीन है, इसलिए कई नोड्स (अपने सिस्टम के लिए जानकारी की जांच करने के लिए अंकतालिका देखें)।
मेमोरी विखंडन भी एक कारण है कि जब मुफ्त मेमोरी होती है तब भी स्वैप का उपयोग बढ़ सकता है।
