ऑपरेटिंग सिस्टम साक्षात्कार: वर्चुअल मेमोरी और पेज फॉल्ट कैसे काम करते हैं?

प्रश्न और लागू होने वाला परिदृश्य

एक Linux सर्विस स्टार्टअप पर 20 GiB रीड-ओनली इंडेक्स को मैप करने के लिए mmap का उपयोग करती है, फिर 8 वर्कर प्रोसेस को fork करती है। मॉनिटरिंग से पता चलता है:

• मैपिंग बनने के तुरंत बाद प्रत्येक प्रोसेस की वर्चुअल मेमोरी लगभग 20 GiB बढ़ जाती है;
• RSS तुरंत उसी मात्रा में नहीं बढ़ता है, लेकिन जैसे-जैसे क्वेरी अधिक इंडेक्स क्षेत्रों को छूती हैं, यह बढ़ता जाता है;
• कोल्ड स्टार्ट के बाद पहले अनुरोधों में लेटेंसी अधिक होती है और अधिक मेजर पेज फॉल्ट होते हैं;
• उन्हीं क्वेरीज़ को दोहराना तेज़ होता है और बहुत कम मेजर फॉल्ट उत्पन्न करता है।

समझाइए कि वर्चुअल एड्रेस फिजिकल एड्रेस कैसे बनते हैं, एक TLB मिस एक पेज फॉल्ट से कैसे भिन्न होता है, Linux पर माइनर और मेजर पेज फॉल्ट का क्या अर्थ है, और सभी 8 वर्कर्स के RSS को जोड़ने से फिजिकल मेमोरी की खपत का अनुमान अधिक (overstate) क्यों हो सकता है। बॉटलनेक को सत्यापित करने और कोल्ड-स्टार्ट लेटेंसी को कम करने की एक विधि के साथ उत्तर समाप्त करें।

यह प्रश्न बैकएंड, इन्फ्रास्ट्रक्चर, सिस्टम्स सॉफ्टवेयर, SRE और परफॉर्मेंस इंजीनियरिंग साक्षात्कारों के लिए उपयुक्त है। नीचे उपयोग की गई 20 GiB मैपिंग, 8 वर्कर्स और 4 KiB पेज साइज़ काल्पनिक अभ्यास धारणाएं हैं, स्रोतों से उत्पादन माप नहीं। इंडेक्स एक रीड-ओनली फाइल मैपिंग है। अनाम मेमोरी (anonymous memory), लिखने योग्य प्राइवेट मैपिंग, कंटेनर मेमोरी सीमाएं और रीयल-टाइम सिस्टम इस जांच को बदल देंगे।

साक्षात्कारकर्ता क्या मूल्यांकन कर रहा है

पहला संकेत यह है कि क्या उम्मीदवार चार परतों को अलग करता है। एक वर्चुअल एड्रेस स्पेस यह बताता है कि एक प्रोसेस क्या एड्रेस कर सकती है। पेज टेबल ट्रांसलेशन और अनुमतियों को स्टोर करती हैं। TLB हाल के ट्रांसलेशन को कैश करता है। फिजिकल पेज में वह डेटा होता है जो वर्तमान में RAM में मौजूद होता है। एक बुनियादी उत्तर कहता है कि वर्चुअल मेमोरी फिजिकल मेमोरी से अधिक हो सकती है; एक मजबूत उत्तर लोड निर्देश (load instruction) के माध्यम से पूरी प्रक्रिया को समझाता है, जिसमें TLB हिट, पेज-टेबल वॉक, रिपेयर करने योग्य फॉल्ट और एक अवैध एक्सेस शामिल है।

दूसरा संकेत यह पहचानना है कि TLB मिस एक पेज फॉल्ट नहीं है। यदि ट्रांसलेशन TLB में अनुपस्थित है लेकिन पेज-टेबल एंट्री मान्य और रेजिडेंट (resident) है, तो प्रोसेसर पेज-टेबल वॉक को पूरा कर सकता है और TLB को भर सकता है। एक पेज फॉल्ट तब होता है जब वर्तमान पेज-टेबल स्थिति एक्सेस को संतुष्ट नहीं कर सकती है, जैसे कि एक गैर-रेजिडेंट पेज, एक पहला राइट जिसके लिए कॉपी-ऑन-राइट की आवश्यकता होती है, या अनुमति का उल्लंघन।

तीसरा संकेत Linux काउंटरों की सही व्याख्या है। एक माइनर फॉल्ट के लिए डिस्क I/O की आवश्यकता नहीं होती है। पेज पहले से ही पेज कैश में हो सकता है लेकिन इस प्रोसेस में मैप नहीं किया गया हो, या कर्नेल एक अनाम पेज आवंटित कर रहा हो या कॉपी-ऑन-राइट पूरा कर रहा हो। एक मेजर फॉल्ट के लिए डिस्क I/O की आवश्यकता होती है। यह स्वैप की गई अनाम मेमोरी को लोड कर सकता है, लेकिन यह एक फाइल-समर्थित (file-backed) मैपिंग को भी पढ़ सकता है जो पेज कैश से अनुपस्थित है। इसलिए, "मेजर फॉल्ट का मतलब स्वैप है" गलत है।

अंत में, साक्षात्कारकर्ता एक साक्ष्य लूप (evidence loop) चाहता है। एक मजबूत उत्तर वार्म-अप, एक अलग इंडेक्स लेआउट, कर्नेल एक्सेस संकेत, या एक छोटे वर्किंग सेट को चुनने से पहले एक ही समय सीमा में रिक्वेस्ट लेटेंसी, फॉल्ट डेल्टा, फाइल-पेज रेजिडेंसी, ब्लॉक-डिवाइस I/O, RSS/PSS और मेमोरी दबाव को संरेखित करता है।

उत्तर देने से पहले स्पष्ट करने वाले प्रश्न

• क्या यह फाइल-समर्थित या अनाम मेमोरी है, और क्या मैपिंग MAP_SHARED है या MAP_PRIVATE? रीड-ओनली फाइल पेजों को पेज कैश के माध्यम से साझा किया जा सकता है। प्राइवेट राइटेबल पेज कॉपी-ऑन-राइट के बाद प्रोसेस-विशिष्ट हो सकते हैं।
• हॉट वर्किंग सेट कितना बड़ा है, और क्या एक्सेस क्रमिक (sequential) है या यादृच्छिक (random)? यदि 95% अनुरोध केवल 2 GiB के हॉट क्षेत्र को छूते हैं, तो सभी 20 GiB को वार्म करने से स्टार्टअप और मेमोरी का दबाव बढ़ जाता है। क्रमिक स्कैन और यादृच्छिक लुकअप के लिए भी अलग-अलग रीड-अहेड विकल्पों की आवश्यकता होती है।
• क्या mmap fork से पहले होता है या बाद में? दोनों दृष्टिकोण एक ही फाइल को मैप कर सकते हैं, लेकिन fork से पहले मैपिंग करने से वर्कर्स के लिए एक कॉन्फ़िगरेशन इनहेरिट करना आसान हो जाता है। प्रत्येक प्रोसेस के पास अभी भी अपनी स्वयं की पेज टेबल और TLB स्थिति होती है।
• क्या मेजर फॉल्ट ब्लॉक रीड और टेल लेटेंसी के साथ ही बढ़ते हैं? कोल्ड-स्टार्ट लागत के अधिकांश हिस्से के लिए डिमांड पेजिंग को जिम्मेदार ठहराने से पहले यह सहसंबंध आवश्यक है। CPU संतृप्ति, लॉक, रिमोट स्टोरेज और इंडेक्स इनिशियलाइज़ेशन एक साथ मौजूद हो सकते हैं।
• क्या स्वैप सक्षम है, क्या कंटेनर या cgroup मेमोरी सीमाएं हैं, और क्या हाल ही में रिक्लेम (reclaim) हुआ है? फाइल-समर्थित मैपिंग बिना स्वैप के भी मेजर फॉल्ट उत्पन्न कर सकती हैं। मेमोरी का दबाव हाल ही में लोड किए गए फाइल पेजों को हटा (evict) सकता है और बार-बार फॉल्ट का कारण बन सकता है।
• तैयारी (readiness) SLO क्या है? 10 सेकंड के भीतर ट्रैफ़िक स्वीकार करने वाली सर्विस आंख मूंदकर 20 GiB को स्कैन नहीं कर सकती है। एक लंबा इनिशियलाइज़ेशन बजट तत्परता से पहले चयनित फॉल्ट को स्थानांतरित करने की अनुमति दे सकता है।

30-सेकंड उत्तर रूपरेखा

"mmap पूरे 20 GiB को पढ़े बिना एक फाइल-समर्थित वर्चुअल रेंज बनाता है, इसलिए VIRT तुरंत बढ़ जाता है जबकि RSS पहले टच पर बढ़ता है। CPU TLB की जांच करता है; जब एंट्री मान्य और रेजिडेंट होती है तो एक मिस को पेज-टेबल वॉक द्वारा हल किया जा सकता है, जबकि एक पेज फॉल्ट को कर्नेल रिपेयर की आवश्यकता होती है। Linux माइनर फॉल्ट के लिए किसी डिस्क I/O की आवश्यकता नहीं होती है; मेजर फॉल्ट के लिए होती है, इसलिए कोल्ड फाइल पेज मेजर फॉल्ट और रिक्वेस्ट लेटेंसी को तब तक बढ़ाते हैं जब तक पेज कैश वार्म नहीं हो जाता। रीड-ओनली पेजों को 8 वर्कर्स द्वारा साझा किया जा सकता है, इसलिए कुल RSS उनकी दोहरी गिनती करता है; PSS का उपयोग करें। फॉल्ट डेल्टा, RssFile/PSS, रीड I/O और p99 को सहसंबद्ध करें, फिर केवल हॉट पेजों को वार्म करें या स्टार्टअप बजट के भीतर madvise और MAP_POPULATE का परीक्षण करें।"

यह रूपरेखा अवलोकनों की व्याख्या करती है, दो सामान्य भ्रमों को अलग करती है, और माप और निर्णय के साथ समाप्त होती है। एक पूर्ण उत्तर को फॉल्ट पाथ और उन स्थितियों की भी व्याख्या करनी चाहिए जिनके तहत प्रत्येक ऑप्टिमाइज़ेशन विफल हो जाता है।

चरण-दर-चरण गहन विश्लेषण

चरण 1: एड्रेस स्पेस, मैपिंग और रेजिडेंट पेजों को अलग करें

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

20 GiB फाइल को मैप करने का तत्काल परिणाम 20 GiB का वर्चुअल मेमोरी क्षेत्र होता है। मैपिंग बताती है कि वह एड्रेस रेंज फाइल से कैसे मेल खाती है; इसके लिए कर्नेल को तुरंत पूरी फाइल पढ़ने की आवश्यकता नहीं होती है। नतीजतन:

• VIRT या VmSize एक ही बार में लगभग 20 GiB बढ़ सकता है;
• अछूते फाइल पेजों को RAM में होने की आवश्यकता नहीं है;
• जब कोई क्वेरी पहली बार किसी पेज को पढ़ती है, तो कर्नेल इसे पेज कैश में लोड कर सकता है और एक पेज-टेबल मैपिंग इंस्टॉल कर सकता है;
• RSS रेजिडेंट हिस्से की गणना करता है, इसलिए यह तब बढ़ता है जब वर्किंग सेट को छुआ जाता है।

4 KiB पेज मानते हुए, पूरे 20 GiB मैपिंग को छूने का मतलब है छूना:

20 × 2^30 ÷ 4096 = 5,242,880 पेज।

यह गणना दर्शाती है कि "सब कुछ वार्म करना" मुफ़्त नहीं है। यदि केवल एक छोटा क्षेत्र हॉट है, तो 5.24 मिलियन से अधिक पेजों को स्कैन करने से मेमोरी में कम मूल्य का डेटा आता है और अन्य उपयोगी कैश प्रविष्टियाँ बाहर हो सकती हैं।

चरण 2: TLB और पेज टेबल के माध्यम से वॉक करें

जब CPU लोड, स्टोर या निर्देश फ़ेच निष्पादित करता है, तो उसे एक वर्चुअल एड्रेस का अनुवाद करना होगा:

1. TLB में वर्चुअल पेज नंबर देखें;
2. TLB हिट होने पर, फिजिकल फ्रेम प्राप्त करें और इसे ऑफसेट के साथ संयोजित करें;
3. TLB मिस होने पर, हार्डवेयर या ऑपरेटिंग सिस्टम को पेज टेबल से परामर्श करने दें;
4. यदि एंट्री मान्य, अनुमत और रेजिडेंट है, तो TLB में ट्रांसलेशन को कैश करें और पुनः प्रयास करें या जारी रखें;
5. यदि वर्तमान एंट्री एक्सेस को संतुष्ट नहीं कर सकती है, तो पेज-फॉल्ट पाथ में प्रवेश करें।

TLB मिस का मतलब है "ट्रांसलेशन कैश मिस हो गया।" पेज फॉल्ट का मतलब है "वर्तमान पेज-टेबल स्थिति इस एक्सेस को पूरा नहीं कर सकती है।" पूर्व केवल एक पेज-टेबल वॉक जोड़ सकता है। उत्तरार्द्ध यह तय करने के लिए कर्नेल में प्रवेश करता है कि एक्सेस कानूनी और रिपेयर करने योग्य है या नहीं। दोनों को भ्रमित करने से यह गलत दावा किया जाता है कि ह्यूज पेज (huge pages), प्रीफेचिंग या तेज़ स्टोरेज क्या ठीक कर सकते हैं।

चरण 3: पेज फॉल्ट को रिपेयर करने योग्य और घातक मामलों में विभाजित करें

पेज फॉल्ट एक अपवाद (exception) है, स्वचालित रूप से प्रोग्राम बग नहीं। कर्नेल पहले एड्रेस और अनुमतियों की जांच करता है:

• कानूनी लेकिन गैर-रेजिडेंट फाइल पेज: फाइल पेज को पढ़ें या मौजूदा पेज-कैश पेज को मैप करें।
• अनाम मेमोरी का पहला कानूनी एक्सेस: पहला रीड साझा शून्य पेज (zero page) को मैप कर सकता है, जबकि पहला राइट एक वास्तविक फिजिकल पेज आवंटित करता है।
• प्राइवेट पेज पर fork के बाद पहला राइट: कॉपी-ऑन-राइट निष्पादित करें और लेखक को एक प्राइवेट कॉपी दें।
• अनमैप्ड एड्रेस या निषिद्ध अनुमति: यदि एक्सेस को रिपेयर नहीं किया जा सकता है, तो SIGSEGV जैसा सिग्नल डिलीवर करें।

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

चरण 4: माइनर और मेजर फॉल्ट की सही व्याख्या करें

Linux एक परिचालन भेद (operational distinction) का उपयोग करता है: क्या फॉल्ट हैंडलिंग के लिए डिस्क I/O की आवश्यकता थी?

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

दो जवाबी उदाहरण उत्तर को मजबूत करते हैं:

1. मेजर फॉल्ट के लिए स्वैप की आवश्यकता नहीं होती है। कोल्ड फाइल-समर्थित मैपिंग के लिए स्टोरेज I/O की आवश्यकता हो सकती है।
2. माइनर फॉल्ट मुफ़्त नहीं है। यह अभी भी कर्नेल में प्रवेश कर सकता है, एक पेज आवंटित कर सकता है, पेज टेबल को अपडेट कर सकता है और एक निर्देश का पुनः प्रयास कर सकता है; यह केवल धीमे डिस्क-I/O पाथ से बचाता है।

चरण 5: बताएं कि कुल RSS भ्रामक क्यों है

जब 8 वर्कर्स एक ही रीड-ओनली फाइल मैपिंग को पढ़ते हैं, तो अंतर्निहित फाइल पेजों को पेज कैश के माध्यम से साझा किया जा सकता है। प्रत्येक प्रोसेस के RSS में उस प्रोसेस में मैप किए गए रेजिडेंट पेज शामिल होते हैं, इसलिए वही फिजिकल पेज कई RSS मानों में दिखाई दे सकता है। सभी 8 RSS मानों को जोड़ने से साझा पेजों की दोहरी गिनती होती है।

कम से कम, इनमें अंतर करें:

• VmSize: वर्चुअल एड्रेस-स्पेस का साइज़;
• VmRSS: इस प्रोसेस के लिए सभी रेजिडेंट पेज;
• RssFile: रेजिडेंट फाइल-समर्थित मैपिंग;
• RssAnon: रेजिडेंट अनाम मेमोरी;
• PSS: उन्हें मैप करने वाली प्रोसेस के बीच आनुपातिक रूप से विभाजित साझा पेज;
• VmPTE: पेज-टेबल प्रविष्टियों द्वारा खपत की गई मेमोरी;
• VmSwap: प्रोसेस के लिए स्वैप किया गया अनाम प्राइवेट डेटा, फाइल मैपिंग का पूरा दृश्य नहीं।

/proc/<pid>/smaps_rollup एक प्रोसेस में सभी मैपिंग के लिए कुल RSS और PSS प्रदान करता है। 8 वर्कर्स के भौतिक पदचिह्न (physical footprint) का अनुमान लगाते समय, PSS का योग आम तौर पर RSS के योग की तुलना में अधिक उपयोगी होता है, हालांकि सिस्टम पेज-कैश प्रतियोगिता और असंबंधित प्रक्रियाएं अभी भी मायने रखती हैं।

चरण 6: पुनरुत्पादनीय अवलोकनों के साथ बॉटलनेक को सत्यापित करें

एकल top स्क्रीनशॉट से निष्कर्ष निकालने के बजाय एक समयरेखा (timeline) बनाएं। Linux परीक्षण परिवेश में, एकत्र करें:

grep -E 'VmSize|VmRSS|RssAnon|RssFile|VmPTE|VmSwap' /proc/$pid/status
cat /proc/$pid/smaps_rollup
perf stat -e page-faults,minor-faults,major-faults -p "$pid" -- sleep 30

फिर ठीक उसी क्वेरी सेट को दो बार चलाएं:

1. कोल्ड स्टार्ट के बाद, अनुरोध p50, p95 और p99, फॉल्ट डेल्टा, ब्लॉक रीड और RSS/PSS रिकॉर्ड करें;
2. समान डेटा, समवर्ती (concurrency) और कोड पाथ के साथ तुरंत दोहराएं;
3. यदि मेजर फॉल्ट, रीड I/O और टेल लेटेंसी पहले रन में अधिक हैं और दूसरे में बहुत कम हैं, तो डिमांड-लोडेड फाइल पेज एक मजबूत प्राथमिक स्पष्टीकरण हैं;
4. यदि मेजर फॉल्ट दुर्लभ हैं जबकि लेटेंसी अधिक बनी रहती है, तो CPU, लॉक, रिमोट कॉल और आंतरिक इंडेक्स इनिशियलाइज़ेशन का निरीक्षण करें;
5. यह देखने के लिए नियंत्रित मेमोरी दबाव के तहत दोहराएं कि क्या हॉट पेजों को रिक्लेम करने से लेटेंसी स्पाइक्स फिर से बनते हैं।

फॉल्ट काउंटर संचयी (cumulative) होते हैं, इसलिए जीवनकाल के कुल योग के बजाय एक ही समय सीमा के भीतर डेल्टा की तुलना करें। वर्कर्स को अलग से मापें ताकि बैकग्राउंड स्कैनर के फॉल्ट को गलत तरीके से ऑनलाइन अनुरोधों के लिए जिम्मेदार न ठहराया जाए।

चरण 7: वर्किंग सेट और SLO से एक ऑप्टिमाइज़ेशन चुनें

सबसे आक्रामक विकल्प स्वतः ही सर्वोत्तम नहीं होता:

1. डिमांड पेजिंग बनाए रखें: सबसे तेज़ स्टार्टअप और वास्तविक वर्किंग सेट के समानुपाती मेमोरी। यह उन वर्कलोड्स के लिए उपयुक्त है जो कोल्ड ट्रैफ़िक को सहन करते हैं या जिनमें बदलते हुए हॉट क्षेत्र होते हैं, जिसकी कीमत पहले-टच लेटेंसी होती है।
2. केवल हॉट पेजों को वार्म करें: तत्परता से पहले प्रतिनिधि क्वेरीज़ चलाएं या हॉट-सेट मैनिफ़ेस्ट से पेजों को स्पर्श करें। यह सीमित लागत को पहले ले आता है और आमतौर पर 20 GiB को स्कैन करने की तुलना में अधिक नियंत्रित होता है, लेकिन हॉट-सेट परिभाषा को बनाए रखा जाना चाहिए।
3. madvise एक्सेस संकेत प्रदान करें: MADV_WILLNEED कहता है कि इस रेंज की जल्द ही आवश्यकता होगी, जिससे रीड-अहेड की अनुमति मिलती है। क्रमिक और यादृच्छिक पैटर्न के लिए भी अलग-अलग संकेत होते हैं। ये प्रदर्शन संकेत हैं, रेजिडेंसी गारंटी नहीं।
4. MAP_POPULATE का परीक्षण करें: यह पेज टेबल को प्रीफॉल्ट करता है और फाइल मैपिंग के लिए रीड-अहेड का कारण बनता है, जिससे बाद में आने वाले ब्लॉकिंग फॉल्ट कम हो जाते हैं। ट्रेडऑफ़ धीमा mmap और स्टार्टअप, केंद्रित I/O और मेमोरी दबाव है, और यह तथ्य कि अधूरा पॉप्युलेशन कॉल को विफल नहीं करता है।
5. इंडेक्स लेआउट और वर्किंग-सेट साइज़ में सुधार करें: हॉट मेटाडेटा को कोल्ड डेटा से अलग करें, लोकैलिटी में सुधार करें और यादृच्छिक क्रॉस-पेज एक्सेस को कम करें। यह अंधाधुंध प्रीफ़ेचिंग की तुलना में अधिक टिकाऊ है।
6. गेट ट्रैफ़िक (Gate traffic): एक परिभाषित हॉट-सेट कवरेज या फॉल्ट-दर लक्ष्य के बाद पूरी तैयारी (readiness) दिखाएं, टाइमआउट के साथ ताकि कोई नोड हमेशा के लिए अप्रस्तुत न रहे।

ह्यूज पेज TLB दबाव को कम कर सकते हैं, लेकिन वे फाइल I/O को नहीं हटाते हैं या खराब चुने गए वर्किंग सेट को ठीक नहीं करते हैं। उनका मूल्यांकन केवल तभी करें जब साक्ष्य TLB मिस को प्राथमिक बॉटलनेक के रूप में पहचानते हैं और मेमोरी ग्रैन्युलैरिटी, विखंडन और परिनियोजन वातावरण स्वीकार्य हैं।

उच्च गुणवत्ता वाला नमूना उत्तर

"मैं पहले पुष्टि करूंगा कि 20 GiB क्षेत्र एक रीड-ओनली फाइल मैपिंग है और mmap fork से पहले होता है। mmap वर्चुअल एड्रेस रेंज और फाइल के बीच एक संबंध बनाता है; यह पूरी फाइल को फिजिकल मेमोरी में नहीं पढ़ता है। इसलिए प्रत्येक वर्कर का VmSize तुरंत लगभग 20 GiB बढ़ जाता है, जबकि RSS केवल तभी बढ़ता है जब क्वेरीज़ पेजों को छूती हैं।

एक एक्सेस पहले TLB की जांच करता है। TLB मिस केवल यह बताता है कि हाल के ट्रांसलेशन कैश में एंट्री की कमी है। यदि पेज-टेबल एंट्री मान्य, अनुमत और रेजिडेंट है, तो पेज-टेबल वॉक और TLB भरण पर्याप्त हैं; कोई पेज फॉल्ट नहीं है। एक फॉल्ट केवल तब होता है जब पेज-टेबल स्थिति एक्सेस को संतुष्ट नहीं कर सकती है, जैसे कि एक गैर-रेजिडेंट फाइल पेज, fork के बाद पहला कॉपी-ऑन-राइट राइट, या एक अवैध अनुमति।

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

वर्कर्स रीड-ओनली फाइल पेजों को साझा कर सकते हैं, लेकिन प्रत्येक वर्कर का RSS उन साझा पेजों की गणना करता है जिन्हें वह मैप करता है। मैं सीधे RSS मान नहीं जोड़ूंगा। मैं /proc/<pid>/smaps_rollup में PSS, RssFile, RssAnon और VmPTE का निरीक्षण करूंगा, फिर उसी 30-सेकंड की विंडो में ब्लॉक रीड, माइनर और मेजर फॉल्ट डेल्टा और अनुरोध p99 के साथ उन्हें संरेखित करूंगा।

सत्यापन के लिए, मैं वही क्वेरी सेट दो बार चलाऊंगा। यदि मेजर फॉल्ट, रीड I/O और p99 पहले रन में उच्च हैं और दूसरे में एक साथ गिरते हैं, तो यह प्राथमिक कारण के रूप में डिमांड लोडिंग का समर्थन करता है। फिर मैं वास्तविक हॉट वर्किंग सेट को मापूँगा। यदि 20 GiB इंडेक्स में से केवल 2 GiB हॉट है, तो मैं तत्परता से पहले उस क्षेत्र को वार्म करूँगा और अनुक्रमिक या यादृच्छिक पहुंच के लिए उपयुक्त madvise संकेत का उपयोग करूँगा। यदि SLO अधिक स्टार्टअप लागत की अनुमति देता है, तो मैं MAP_POPULATE के साथ A/B परीक्षण चलाऊंगा। मैं डिफ़ॉल्ट रूप से पूरी फ़ाइल को स्कैन नहीं करूंगा या ह्यूज पेजों को जेनेरिक पेज-फ़ॉल्ट फिक्स के रूप में नहीं मानूंगा। अंतिम निर्णय स्टार्टअप समय, पहले मिनट के p99, मेजर-फॉल्ट दर, PSS और मेमोरी रिक्लेम के बाद स्थिरता की तुलना करेगा।"

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

सामान्य गलतियाँ

• VIRT को पहले से उपभोग की गई RAM मानना → एक फाइल मैपिंग प्रत्येक पेज को रेजिडेंट बनाए बिना एक एड्रेस रेंज आरक्षित कर सकती है → VmSize, RSS, PSS और मैपिंग प्रकार का एक साथ निरीक्षण करें।
• TLB मिस को पेज फॉल्ट के बराबर समझना → एक मान्य रेजिडेंट पेज-टेबल एंट्री को केवल ट्रांसलेशन की आवश्यकता होती है → TLB लुकअप, पेज-टेबल वॉक और फॉल्ट स्थिति का अलग-अलग वर्णन करें।
• यह दावा करना कि प्रत्येक पेज फॉल्ट डिस्क को पढ़ता है → पेज-कैश हिट, अनाम शून्य पेज और कॉपी-ऑन-राइट माइनर फॉल्ट उत्पन्न कर सकते हैं → Linux माइनर/मेजर I/O भेद का उपयोग करें।
• यह दावा करना कि मेजर फॉल्ट केवल स्वैप से आते हैं → एक अनकैश्ड फाइल-समर्थित पेज के लिए स्टोरेज I/O की भी आवश्यकता होती है → पहचानें कि फॉल्टिंग पेज अनाम है या फाइल-समर्थित।
• सभी 8 वर्कर्स के RSS को जोड़ना → साझा फाइल पेजों की बार-बार गिनती की जाती है → साझा पेजों को विभाजित करने के लिए PSS का उपयोग करें और RssFile की RssAnon से तुलना करें।
• लाइफटाइम फॉल्ट योग को पढ़ना → वे किसी विशेष धीमी अनुरोध विंडो से संबंध साबित नहीं करते हैं → एक ही अंतराल में फॉल्ट डेल्टा, I/O और लेटेंसी की तुलना करें।
• स्टार्टअप के दौरान सभी 20 GiB को स्कैन करना → यह I/O को बर्बाद कर सकता है, तत्परता में देरी कर सकता है और अधिक उपयोगी पेजों को हटा सकता है → हॉट सेट को मापें और केवल वही वार्म करें जो SLO के लिए आवश्यक है।
• यह मान लेना कि MADV_WILLNEED या MAP_POPULATE भविष्य के फॉल्ट को समाप्त करता है → पहला एक संकेत है, दूसरा अधूरा हो सकता है, और पेजों को बाद में पुनः प्राप्त (reclaim) किया जा सकता है → कोल्ड-स्टार्ट और मेमोरी-दबाव व्यवहार का परीक्षण करें।
• ह्यूज पेजों को तुरंत सक्षम करना → वे मुख्य रूप से ट्रांसलेशन कवरेज और आवंटन ग्रैन्युलैरिटी को बदलते हैं, न कि फाइल I/O या वर्किंग-सेट गुणवत्ता को → पहले साबित करें कि TLB मिस हावी हैं।

अनुवर्ती प्रश्न और उत्तर

अनुवर्ती 1: मशीन पर कोई स्वैप नहीं है। फिर भी मेजर पेज फॉल्ट क्यों हैं?

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

अनुवर्ती 2: किसी अन्य वर्कर ने पहले ही वही फाइल पेज पढ़ लिया है। इस वर्कर के पहले एक्सेस पर क्या होता है?

पेज पहले से ही सिस्टम पेज कैश में हो सकता है जबकि इस वर्कर के पास इसके लिए पेज-टेबल मैपिंग का अभाव है। उस मैपिंग को स्थापित करने के लिए आमतौर पर किसी डिस्क I/O की आवश्यकता नहीं होती है और यह एक माइनर फॉल्ट के रूप में दिखाई दे सकता है। बाद के एक्सेस में अभी भी TLB मिस हो सकता है, लेकिन यदि पेज-टेबल एंट्री मान्य है, तो वह पेज फॉल्ट नहीं है।

अनुवर्ती 3: fork के बाद थोड़ी मात्रा में लिखने से PSS क्यों बढ़ सकता है?

प्राइवेट पेजों को शुरुआत में कॉपी-ऑन-राइट के माध्यम से साझा किया जा सकता है। पहले राइट पर, कर्नेल राइट करने वाले वर्कर के लिए एक प्राइवेट कॉपी बनाता है और उसकी पेज टेबल को अपडेट करता है। एक साझा पेज एक प्रक्रिया के लिए जिम्मेदार हो जाता है, इसलिए PSS बढ़ जाता है। फॉल्ट के लिए आम तौर पर किसी डिस्क I/O की आवश्यकता नहीं होती है, लेकिन आवंटन और प्रतिलिपि बनाने में अभी भी समय लगता है। एक रीड-ओनली इंडेक्स को प्राइवेट मैपिंग में आकस्मिक राइट से बचना चाहिए।

अनुवर्ती 4: यदि एक्सेस यादृच्छिक है लेकिन सर्विस MADV_SEQUENTIAL का उपयोग करती है तो क्या होगा?

एक बेमेल संकेत बेकार रीड-अहेड को ट्रिगर कर सकता है, ऐसे पेजों को लोड कर सकता है जिनका उपयोग नहीं किया जाएगा और I/O बढ़ जाएगा। रैंडम पॉइंट लुकअप के लिए, MADV_RANDOM या डिफ़ॉल्ट नीति का परीक्षण करें; यदि हॉट सेट ज्ञात है, तो लक्षित प्रीफ़ेचिंग बेहतर है। प्रत्येक संकेत को उसके नाम के बजाय फॉल्ट, I/O, PSS और लेटेंसी द्वारा आंकें।

अनुवर्ती 5: MAP_POPULATE कब उपयुक्त है?

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

अनुवर्ती 6: आप पेज-फॉल्ट चर्न को वास्तविक मेमोरी लीक से कैसे अलग करेंगे?

एक लीक आमतौर पर प्राइवेट अनाम मेमोरी या गैर-पुनर्प्राप्ति योग्य वस्तुओं को स्थिर ट्रैफ़िक के तहत भी लगातार बढ़ते हुए दिखाता है। फाइल-समर्थित वर्किंग सेट में वृद्धि RssFile और पेज कैश में अधिक दिखाई देती है और रिक्लेम के बाद गिर सकती है। RssAnon, RssFile, PSS, VmSwap और हीप या ऑब्जेक्ट प्रोफाइल की तुलना करें, फिर स्थिर ट्रैफ़िक और नियंत्रित मेमोरी दबाव के तहत दोहराएं। अकेले RSS वृद्धि दोनों के बीच अंतर नहीं कर सकती है।