यह दृश्य कई वास्तविक दुनिया के मामलों में बहुत भ्रामक हो सकता है।
कर्नेल अब MemAvailableक्षेत्र में उपलब्ध स्मृति के लिए एक अनुमान प्रदान करता है । यह मान काफी अलग है MemFree + Cached।
/ proc / meminfo: अनुमानित उपलब्ध स्मृति प्रदान करें [गिरी परिवर्तन विवरण, 2014]
कितने लोड संतुलन और कार्यभार रखने वाले प्रोग्राम चेक / प्रोक / मेमोफियो को यह अनुमान लगाने के लिए कि कितनी मुफ्त मेमोरी उपलब्ध है। वे आम तौर पर "फ्री" और "कैश्ड" को जोड़कर ऐसा करते हैं, जो दस साल पहले ठीक था, लेकिन आज बहुत गलत होने की गारंटी है।
यह गलत है क्योंकि कैश्ड में मेमोरी शामिल होती है जो पेज कैश के रूप में फ्रीज नहीं होती है, उदाहरण के लिए साझा मेमोरी सेगमेंट, टैम्पफ और रम्फ्स, और इसमें रीक्लेमेबल स्लैब मेमोरी शामिल नहीं है, जो कि ज्यादातर आईडी सिस्टम पर सिस्टम मेमोरी का एक बड़ा अंश ले सकती है। बहुत सारी फाइलें।
वर्तमान में, एक नए वर्कलोड के लिए उपलब्ध मेमोरी की मात्रा, सिस्टम को स्वैप में धकेलने के बिना, मेमफ्री, एक्टिव (फाइल), इनएक्टिव (फाइल), और एसआरकेलेबल, साथ ही साथ "निम्न" वॉटरमार्क से अनुमान लगाया जा सकता है। proc / zoneinfo। हालांकि, यह भविष्य में बदल सकता है, और उपयोगकर्ता स्थान वास्तव में कर्नेल आंतरिक को मुफ्त मेमोरी की मात्रा के लिए एक अनुमान के साथ जानने की उम्मीद नहीं की जानी चाहिए। / Proc / meminfo में ऐसा अनुमान प्रदान करना अधिक सुविधाजनक है। अगर भविष्य में चीजें बदलती हैं, तो हमें केवल एक ही स्थान पर इसे बदलना होगा।
...
प्रलेखन / filesystems / proc.txt:
...
MemAvailable: नए अनुप्रयोगों को शुरू करने के लिए, स्वैप किए बिना कितनी मेमोरी उपलब्ध है, इसका एक अनुमान। मेमरी, SReclaimable, फ़ाइल LRU सूचियों के आकार और प्रत्येक क्षेत्र में कम वॉटरमार्क से परिकलित। अनुमान इस बात को ध्यान में रखता है कि सिस्टम को अच्छी तरह से काम करने के लिए कुछ पेज कैश की आवश्यकता होती है, और यह कि सभी पुन: प्राप्य स्लैब पुनः प्राप्त करने योग्य नहीं होंगे, क्योंकि आइटम उपयोग में हैं। उन कारकों का प्रभाव सिस्टम से सिस्टम में अलग-अलग होगा।
1. MemAvailable विवरण
जैसा कि ऊपर कहा गया है, tmpfs और अन्य Shmemमेमोरी को मुक्त नहीं किया जा सकता है, केवल स्वैप करने के लिए स्थानांतरित किया गया है। Cachedमें /proc/meminfoबहुत, भ्रामक इस swappable सहित के कारण हो सकता Shmemस्मृति। यदि आपके पास tmpfs में बहुत अधिक फाइलें हैं, तो यह आपकी मेमोरी :-) पर बहुत अधिक कब्जा कर सकता है। Shmemइसमें कुछ ग्राफिक्स मेमोरी आवंटन भी शामिल हो सकते हैं , जो बहुत बड़े हो सकते हैं।
MemAvailableजानबूझकर इसमें स्वैपेबल मेमोरी शामिल नहीं है। बहुत ज्यादा स्वैप करने से लंबी देरी हो सकती है। तुम भी स्वैप स्थान के बिना चलाने के लिए चुना हो सकता है, या केवल एक अपेक्षाकृत सीमित राशि की अनुमति दी।
मुझे डबल-चेक करना है कि कैसे MemAvailableकाम करता है। पहली नज़र में, कोड को इस भेद का उल्लेख नहीं लगता था।
/*
* Not all the page cache can be freed, otherwise the system will
* start swapping. Assume at least half of the page cache, or the
* low watermark worth of cache, needs to stay.
*/
pagecache = pages[LRU_ACTIVE_FILE] + pages[LRU_INACTIVE_FILE];
pagecache -= min(pagecache / 2, wmark_low);
available += pagecache;
हालांकि, मैंने पाया कि यह Shmem"उपयोग" मेमोरी के रूप में सही ढंग से व्यवहार करता है । मैंने एक tmpfs में कई 1GB फाइलें बनाईं। में प्रत्येक 1GB वृद्धि Shmemकम MemAvailable1GB द्वारा। तो "फ़ाइल LRU सूचियों" के आकार में साझा मेमोरी या किसी अन्य स्वैपेबल मेमोरी शामिल नहीं है। (मैंने देखा कि ये वही पृष्ठ गणना कोड में भी उपयोग किए जाते हैं जो "गंदी सीमा" की गणना करता है )।
यह MemAvailableगणना भी मानती है कि आप कर्नेल के "कम वॉटरमार्क" के बराबर कम से कम पर्याप्त फ़ाइल कैश रखना चाहते हैं। या वर्तमान कैश का आधा - जो भी छोटा है। (यह पुनः प्राप्त स्लैब के लिए भी यही धारणा बनाता है)। कर्नेल के "कम वॉटरमार्क" को ट्यून किया जा सकता है, लेकिन यह आमतौर पर सिस्टम रैम का लगभग 2% होता है । इसलिए यदि आप केवल एक मोटा अनुमान चाहते हैं, तो आप इस भाग को अनदेखा कर सकते हैं :-)।
जब आप firefoxलगभग 100MB प्रोग्राम कोड के साथ पेज कैश में मैप कर रहे हैं , तो आप आमतौर पर उस 100MB को RAM :-) में रखना चाहते हैं। अन्यथा, सबसे अच्छे रूप में आप देरी का सामना करेंगे, सबसे खराब प्रणाली विभिन्न अनुप्रयोगों के बीच अपना सारा समय पिटाई में बिताएगी । तो इसके MemAvailableलिए एक छोटा प्रतिशत RAM की अनुमति दे रहा है। यह पर्याप्त अनुमति नहीं दे सकता है, या यह अधिक उदार हो सकता है। "उन कारकों का प्रभाव सिस्टम से सिस्टम में अलग-अलग होगा"।
कई पीसी वर्कलोड के लिए, "बहुत सारी फाइलें" के बारे में बात प्रासंगिक नहीं हो सकती है। फिर भी, मेरे पास वर्तमान में अपने लैपटॉप पर (8GB RAM में से) 500MB पुनर्प्राप्त करने योग्य स्लैब मेमोरी है। यह ext4_inode_cache(300K से अधिक ऑब्जेक्ट) के कारण है। ऐसा इसलिए हुआ क्योंकि मुझे हाल ही में पूरे फाइल सिस्टम को स्कैन करना था, यह जानने के लिए कि मेरे डिस्क स्पेस का उपयोग क्या था :-)। मैंने कमांड का उपयोग किया df -x / | sort -n, लेकिन उदाहरण के लिए गनोम डिस्क यूसेज एनालाइजर यही काम करेगा।
2. [संपादित करें] नियंत्रण समूहों में मेमोरी
तथाकथित "लिनक्स कंटेनरों" से बने होते हैं namespaces, cgroupsऔर स्वाद के अनुसार विभिन्न अन्य सुविधाओं :-)। वे लगभग पूर्ण लिनक्स सिस्टम की तरह कुछ चलाने के लिए एक पर्याप्त वातावरण प्रदान कर सकते हैं। होस्टिंग सेवाएँ इस तरह कंटेनरों का निर्माण कर सकती हैं और उन्हें "वर्चुअल सर्वर" :-) के रूप में बेच सकती हैं।
होस्टिंग सर्वर उन सुविधाओं का उपयोग करके "वर्चुअल सर्वर" भी बना सकते हैं जो मेनलाइन लिनक्स में नहीं हैं। OpenVZ कंटेनरों ने दो साल की तारीख से पहले मेनलाइन cgroups, और स्मृति को सीमित करने के लिए "बीनकाउंटर्स" का उपयोग कर सकते हैं। तो आप ठीक से समझ नहीं सकते हैं कि यदि आप केवल दस्तावेज़ पढ़ते हैं या मेनलाइन लिनक्स कर्नेल के बारे में सवाल पूछते हैं तो वे मेमोरी लिमिट कैसे काम करते हैं। cat /proc/user_beancountersवर्तमान उपयोग और सीमा दिखाता है। vzubcइसे थोड़ा और अनुकूल प्रारूप में प्रस्तुत करता है। Beancounters पर मुख्य पेज पंक्ति के नाम दर्ज होते हैं।
नियंत्रण समूहों में उनके अंदर प्रक्रियाओं पर मेमोरी सीमा निर्धारित करने की क्षमता शामिल है। यदि आप इस तरह के cgroup के अंदर अपना एप्लिकेशन चलाते हैं, तो सिस्टम की सभी मेमोरी एप्लीकेशन को उपलब्ध नहीं होगी। तो, हम इस मामले में उपलब्ध स्मृति को कैसे देख सकते हैं?
यदि आप cgroup-v1 या cgroup-v2 का उपयोग करते हैं, तो इसके लिए इंटरफ़ेस कई तरीकों से भिन्न होता है ।
मेरा लैपटॉप स्थापित cgroup-v1 का उपयोग करता है। मैं दौड़ सकता हूं cat /sys/fs/cgroup/memory/memory.stat। फ़ाइल सहित विभिन्न क्षेत्रों से पता चलता total_rss, total_cache, total_shmem। shmem, tmpfs सहित, स्मृति सीमा की ओर गिना जाता है। मुझे लगता है कि आप इसके total_rssविपरीत के रूप में देख सकते हैं MemFree। और फ़ाइल भी है memory.kmem.usage_in_bytes, स्लैब सहित कर्नेल मेमोरी का प्रतिनिधित्व करता है। (मुझे लगता है कि memory.kmem.इसमें memory.kmem.tcp.और भविष्य के एक्सटेंशन भी शामिल हैं , हालांकि यह स्पष्ट रूप से प्रलेखित नहीं है)। पुनर्प्राप्त करने योग्य स्लैब मेमोरी देखने के लिए अलग काउंटर नहीं हैं। Cgroup-v1 के लिए दस्तावेज़ का कहना है कि मेमोरी की सीमा को मारने से किसी भी स्लैब मेमोरी की पुनः प्राप्ति ट्रिगर नहीं होती है । (दस्तावेज़ में एक अस्वीकरण भी है कि यह "निराशाजनक रूप से पुराना" है, और आपको वर्तमान स्रोत कोड की जांच करनी चाहिए)।
cgroup-v2 अलग है। मुझे लगता है कि रूट (टॉप-लेवल) cgroup मेमोरी अकाउंटिंग का समर्थन नहीं करता है। cgroup-v2 में अभी भी एक memory.statफ़ाइल है। सभी क्षेत्र बच्चे cgroups पर योग करते हैं, इसलिए आपको total_...फ़ील्ड देखने की आवश्यकता नहीं है । एक fileक्षेत्र है, जिसका मतलब वही है जो cacheकिया गया था। शायद ही मैं rssअंदर की तरह एक समग्र क्षेत्र नहीं देखता memory.stat; मुझे लगता है कि आपको व्यक्तिगत क्षेत्रों को जोड़ना होगा। पुन: प्राप्य और अप्राप्य स्लैब मेमोरी के लिए अलग-अलग आँकड़े हैं; मुझे लगता है कि v2 cgroup को स्लैब को पुनः प्राप्त करने के लिए डिज़ाइन किया गया है जब यह मेमोरी पर कम चलना शुरू करता है।
लिनक्स cgroups स्वचालित रूप से वर्चुअलाइजेशन /proc/meminfo(या किसी अन्य फ़ाइल में /proc) नहीं करते हैं, जिससे पूरे मशीन के लिए मान दिखाई देंगे। यह VPS ग्राहकों को भ्रमित करेगा। हालाँकि , विशिष्ट कंटेनर सॉफ़्टवेयर द्वारा फ़ेक की गई/proc/meminfo फ़ाइल के साथ नामस्थानों का उपयोग करना संभव है । नकली मूल्य कितने उपयोगी हैं, यह इस बात पर निर्भर करेगा कि विशिष्ट सॉफ्टवेयर क्या करता है।
systemdविश्वास है कि cgroup-v1 को कंटेनरों में सुरक्षित रूप से नहीं भेजा जा सकता है। मैंने systemd-nspawnअपने cgroup-v1 सिस्टम पर एक कंटेनर के अंदर देखा । मैं देख सकता हूँ कि यह अंदर रखा गया cgroup है, और उस पर मेमोरी अकाउंटिंग है। दूसरी ओर निहित systemdसंसाधन लेखांकन के लिए सामान्य प्रति-सेवा cgroups सेट नहीं करता है। यदि मेमोरी लेखा इस cgroup के अंदर सक्षम नहीं किया गया था, मुझे लगता है कि कंटेनर इसे सक्षम करने में सक्षम नहीं होगा।
मुझे लगता है कि यदि आप एक cgroup-v2 कंटेनर के अंदर हैं, तो यह वास्तविक cgroup-v2 सिस्टम की जड़ के लिए अलग दिखेगा, और आप इसके शीर्ष-स्तरीय cgroup के लिए मेमोरी अकाउंटिंग देख पाएंगे। या यदि आप जिस क्रूपग्रुप को देख सकते हैं उसमें मेमोरी अकाउंटिंग सक्षम नहीं है, तो उम्मीद है कि आपको अनुमति दी जाएगी ताकि आप मेमोरी अकाउंटिंगsystemd (या समतुल्य) को सक्षम कर सकें ।
MemAvailable, यह 3.14 में जोड़ा गया था।