स्वैच्छिकता डिफ़ॉल्ट रूप से 60 पर सेट क्यों है?


109

मैंने अभी लिनक्स पर स्वैग के बारे में कुछ चीजें पढ़ी हैं। मुझे समझ नहीं आता कि डिफ़ॉल्ट 60 पर सेट क्यों है।

मेरे अनुसार स्वैप को कम करने के लिए इस पैरामीटर को 10 पर सेट किया जाना चाहिए। स्वैप मेरी हार्ड ड्राइव पर है इसलिए यह मेरी मेमोरी की तुलना में बहुत धीमा है।

उन्होंने कर्नेल को इस तरह क्यों कॉन्फ़िगर किया?


2
@Mat देखें इस कैसे swappiness बेंच मार्किंग करने के लिए।
गेरिमिया

जवाबों:


133

कर्नेल २.६.२ Linux के बाद से, लिनक्स एक स्प्लिट लेस्ट रिसेंटली यूज्ड (LRU) पेज रिप्लेसमेंट रणनीति का उपयोग करता है । एक फाइल सिस्टम स्रोत वाले पृष्ठ, जैसे प्रोग्राम टेक्स्ट या साझा लाइब्रेरी फ़ाइल कैश के हैं। फाइलसिस्टम बैकिंग वाले पृष्ठों को गुमनाम पृष्ठ कहा जाता है, और रनटाइम डेटा से युक्त होते हैं जैसे कि अनुप्रयोगों के लिए आरक्षित स्टैक स्थान आदि। आमतौर पर फ़ाइल कैश से संबंधित पृष्ठ मेमोरी से बेदखल करने के लिए सस्ते होते हैं (जब ये आवश्यक हो तो डिस्क से वापस पढ़ा जा सकता है) । चूंकि अनाम पृष्ठों का कोई फाइल सिस्टम बैकिंग नहीं है, इसलिए उन्हें तब तक मेमोरी में रहना चाहिए, जब तक उन्हें किसी प्रोग्राम की आवश्यकता न हो, जब तक कि उन्हें स्टोर करने के लिए स्वैप स्पेस न हो।

यह एक आम गलत धारणा है कि एक स्वैप विभाजन किसी तरह आपके सिस्टम को धीमा कर देगा। स्वैप विभाजन नहीं होने का मतलब यह नहीं है कि कर्नेल मेमोरी से पेजों को बेदखल नहीं करेगा, इसका मतलब सिर्फ यह है कि कर्नेल के पास कम विकल्प हैं कि कौन से पेजों को बेदखल करें। उपलब्ध स्वैप की मात्रा यह प्रभावित नहीं करेगी कि इसका कितना उपयोग किया जाता है।

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

vm.swappinessविकल्प के लिए एक आपरिवर्तक कि गुमनाम पृष्ठों के पक्ष में फ़ाइल कैश पृष्ठों बाहर गमागमन के बीच संतुलन को बदल देता है। फ़ाइल कैश को 200 का एक मनमाना प्राथमिकता मूल्य दिया जाता है जिसमें से vm.swappinessसंशोधक काटा जाता है ( file_prio=200-vm.swappiness)। अनाम पृष्ठ, डिफ़ॉल्ट रूप से, 60 ( anon_prio=vm.swappiness) से शुरू होते हैं । इसका मतलब यह है कि, डिफ़ॉल्ट रूप से, प्राथमिकता वाले वज़न गुमनाम पृष्ठों ( anon_prio=60, file_prio=200-60=140) के पक्ष में हैं । व्यवहार को mm/vmscan.cकर्नेल स्रोत ट्री में परिभाषित किया गया है।

एक को देखते हुए vm.swappinessकी 100, प्राथमिकताओं बराबर होगा ( file_prio=200-100=100, anon_prio=100)। यह एक I / O भारी प्रणाली के लिए समझ में आता है अगर यह नहीं चाहता है कि फ़ाइल कैश से पृष्ठों को गुमनाम पृष्ठों के पक्ष में बेदखल किया जाए।

इसके विपरीत सेटिंग करने vm.swappinessसे 0कर्नेल को फ़ाइल कैश से पृष्ठों के पक्ष में अनाम पृष्ठों को बेदखल करने से रोका जा सकेगा। यह उपयोगी हो सकता है यदि प्रोग्राम अपने अधिकांश कैशिंग स्वयं करते हैं, जो कुछ डेटाबेस के साथ हो सकता है। डेस्कटॉप सिस्टम में यह अन्तरक्रियाशीलता में सुधार कर सकता है, लेकिन नकारात्मक पक्ष यह है कि I / O प्रदर्शन संभवतः हिट होगा।

डिफ़ॉल्ट मूल्य को इन दो चरम सीमाओं के बीच अनुमानित मध्यभूमि के रूप में चुना गया है। किसी भी प्रदर्शन पैरामीटर के साथ, समायोजन vm.swappinessवास्तविक कार्यभार के बराबर बेंचमार्क डेटा पर आधारित होना चाहिए, न कि केवल एक आंत भावना।


4
ओएस को एक ठोस राज्य डिवाइस पर स्थापित करने से ट्रेडऑफ़ कैसे प्रभावित होता है?
जरीट

3
@gerrit अंतर्निहित भंडारण माध्यम का प्रकार अप्रासंगिक है। मेमोरी प्रबंधन सबसिस्टम के लिए उस तरह का विवरण दिखाई नहीं देता है।
थॉमस निमन

अंतर्निहित भंडारण माध्यम का प्रकार स्मृति उपयोग के दृष्टिकोण से अप्रासंगिक है। आप स्वपन को कम करने पर विचार कर सकते हैं कि माध्यम अपनी दीर्घायु को बढ़ाने के लिए सीमित मात्रा में रीड / राइट्स (यानी फ्लैश मेमोरी) का समर्थन करता है।
MatrixManAtYrService

2
@MatrixManAtYrService आंतरिक वियर-लेवलिंग और बिल्ट-इन अतिरेक, आधुनिक SSDs (जो पिछली टिप्पणी में प्रश्न का उल्लेख करता है) के लिए धन्यवाद त्रुटियों को स्वीकार करने से पहले लिखने के 2 PB (!) तक दिखाया गया है । यहां तक ​​कि उन प्रयोगों में सस्ती ड्राइव 300TB के लिए चली गई त्रुटियों से पहले, लगभग 100TB की आधिकारिक वारंटी रेटिंग से परे है। कम से कम मेरी राय में वर्कस्टेशन या लैपटॉप पर एक एसएसडी के लिए स्वैग को समायोजित करना वास्तव में वारंट नहीं है।
थॉमस निमन

2
@ThomasNyman आप एक अच्छा बिंदु बनाते हैं, अधिकांश उपयोगकर्ताओं के लिए यह चिंता करने लायक नहीं है। जो मामला मुझे इस पोस्ट में लाया गया, उसमें एसडी कार्ड पर स्वैप स्पेस शामिल था, जिसे मैं पहचानता हूं कि यह एक किनारे का मामला है।
MatrixManAtYrService

9

समस्या यह है कि कोई भी डिफ़ॉल्ट मान नहीं है जो सभी आवश्यकताओं के अनुरूप हो। 10 के लिए स्वैपीनेस विकल्प सेट करना डेस्कटॉप के लिए एक उपयुक्त सेटिंग हो सकती है, लेकिन सर्वर के लिए 60 का डिफ़ॉल्ट मान अधिक उपयुक्त हो सकता है। दूसरे शब्दों में उपयोग के मामले के अनुसार स्वेप्टनेस को ट्विक करने की आवश्यकता है - डेस्कटॉप बनाम सर्वर, एप्लिकेशन प्रकार और इसी तरह।

इसके अलावा, लिनक्स कर्नेल डिस्क कैश के लिए मेमोरी का उपयोग करता है अन्यथा रैम का उपयोग नहीं किया जाएगा और यह कुशल और इरादा नहीं है। कैश में डिस्क डेटा होने का मतलब है कि अगर किसी चीज़ को फिर से उसी डेटा की ज़रूरत है, तो यह संभवतः इसे मेमोरी से प्राप्त करेगा। डेटा को फिर से प्राप्त करना डिस्क से फिर से प्राप्त करने की तुलना में अधिक तेज है। और स्वैपीनेस विकल्प एक तंत्र है जो लिनक्स कर्नेल डिस्क कैश को सिकोड़ने के लिए डिस्क से स्वैपिंग को प्राथमिकता देता है। क्या इसे कैश से पुराने डेटा को निकालना चाहिए या इसे कुछ प्रोग्राम पेजों को स्वैप करना चाहिए?

इस लेख में विषय पर कुछ प्रकाश डाला जा सकता है। खासकर, स्वैपिंग की प्रवृत्ति का अनुमान कैसे लगाया जाता है।


मुझे समझ नहीं आता कि 60 सर्वरों के लिए अधिक उपयुक्त क्यों है। मेरे पास सर्वर हैं और कुछ प्रक्रियाएं स्वैप में जाती हैं, भले ही हमारे पास 40% फ्रीम रैम हो। मेरे लिए कोई मतलब नहीं है।
ह्यूगो

7
यह स्मृति के कुछ हिस्सों को स्वैप में स्थानांतरित करने के लिए समझ में आता है यदि यह बहुत संभावना नहीं है कि वे एक्सेस करने जा रहे हैं, तो इस तरह से लिनक्स वास्तविक राम के लिए उतने ही मुक्त रखता है जितना संभव हो स्थितियों के लिए तैयार रहना जब इसे वास्तव में इसकी आवश्यकता होती है।
फिर से खेलना


लेख का लिंक मर चुका है, लेकिन आप इसे अभी भी वेनबैक मशीन
22

जुड़ा हुआ लेख जानकारीपूर्ण है। इसे शेयर करने के लिए धन्यवाद।
पिस्तोस

5

ऊपर दिए गए उत्तरों में और अधिक विवरण जोड़ना।
जैसा कि हम VM के अधिक से अधिक उपयोग कर रहे हैं, एक linux host इन क्लाउड वातावरणों में से एक पर vm हो सकता है। 1 और 2 दोनों उदाहरणों में हमें चल रहे अनुप्रयोगों का अच्छा विचार है और इसलिए वे कितनी रैम का उपभोग करते हैं। 3 में, इतना नहीं

  • उदाहरण 1
    एक उच्च प्रदर्शन निजी क्लाउड (लगता है कि अधिकांश बैंक लाखों का भुगतान करेंगे) एक जहां डिस्क बहुत अच्छा भंडारण सरणी द्वारा बहुत अच्छा IO प्रदान किया जाता है। उस स्टोरेज का एक भाग SSD डिस्क द्वारा समर्थित रैम (डिस्क एरे में) हो सकता है, स्पिंडल के साथ नियमित डिस्क द्वारा समर्थित। इस स्थिति में वीएम जो डिस्क देखता है वह रैम की तुलना में केवल थोड़ा धीमा हो सकता है। एक एकल vm के लिए स्वैप और राम में बहुत अंतर नहीं है।
  • उदाहरण 2
    उदाहरण 1 के समान लेकिन एकल vm के बजाय आपके पास सैकड़ों, हजारों या अधिक हैं। इस स्थिति में हमें पता चलता है कि सर्वर (हाइपरवाइजर) रैम सस्ता और भरपूर है जहां स्टोरेज रैम महंगा (अपेक्षाकृत बोलने वाला) है। यदि हम अपने बहुत महंगे स्टोरेज ऐरे द्वारा प्रदत्त हाइपवाइज़र रैम और SWAP के बीच रैम की आवश्यकताओं को विभाजित करते हैं, तो हम पाते हैं कि हम स्टोरेज ऐरे में सभी रैम का उपयोग करते हैं, फिर ब्लॉक SSD के द्वारा और अंत में स्पिंडल द्वारा परोसे जाते हैं। अचानक हर कोई वास्तव में धीमा होने लगता है। इस मामले में हम शायद VM को बहुत सारे RAM (हाइपरविजर से) असाइन करना चाहते हैं और स्वैगनेस को 0 पर सेट करना चाहते हैं (केवल मेमोरी की स्थिति से बचने के लिए स्वैप) क्योंकि उन सभी वीएम के संचयी प्रभाव का प्रदर्शन पर प्रभाव पड़ेगा भंडारण,
  • उदाहरण 3 एक आधुनिक लैपटॉप या डेस्कटॉप शायद एक एसएसडी के साथ। स्मृति आवश्यकताओं को अज्ञात माना जाता है। कौन सा ब्राउज़र उपयोगकर्ता का उपयोग करेगा, उनके पास कितने टैब खुले होंगे, क्या वे एक दस्तावेज़, एक रॉ छवि या संभवतः एक वीडियो का संपादन भी करेंगे, वे सभी रैम का उपभोग करेंगे। स्वैग को कम मूल्य पर सेट करना और अन्य फाइल सिस्टम को ट्विस्ट करने का मतलब होगा कि एसएसडी को कम लिखना है और इसलिए यह अधिक समय तक चलेगा।

3
SSD एक एंड-यूज़र सिस्टम के लिए धीरज चिंताओं को लिखते हैं। आधुनिक एसएसडी आमतौर पर कई सैकड़ों टेराबाइट्स की मात्राओं को लिखते हैं। भारी स्वैप उपयोग के साथ एक विशिष्ट डेस्कटॉप सिस्टम भी ऑपरेशन के कई वर्षों के लिए उपयोग करने की संभावना नहीं है।
जूल्स
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.