लिनक्स में कैश क्यों छोड़ें?


84

हमारे सर्वर में हमें आधी रात को कैश छोड़ने की आदत है।

sync; echo 3 > /proc/sys/vm/drop_caches

जब मैं कोड को चलाता हूं तो यह बहुत सारी रैम को मुक्त करता है, लेकिन क्या मुझे वास्तव में ऐसा करने की आवश्यकता है। क्या RAM मुफ्त नहीं है?


62
उस व्यक्ति को ढूंढें जिसने इसे रखा था और उससे पूछें कि उसने ऐसा क्यों किया। जैसा कि आपने सही अनुमान लगाया है, इसका कोई स्पष्ट अच्छा कारण नहीं है।
माइकल हैम्पटन

10
कर्नेल डिबगिंग। यह इसके बारे में। यह वास्तव में किसी भी रैम को मुक्त नहीं करता है; जैसा कि नाम से पता चलता है, यह कैश छोड़ देता है और इस तरह प्रदर्शन को कम करता है।
माइकल हैम्पटन

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

7
संबंधित thedailywtf.com/Articles/Modern-Memory-Management.aspx दृढ़ता से यह एक बुरा विचार है।
Drunix

7
संबंधित और "समस्या" का एक उपयोगी विवरण: linuxatemyram.com
बिल वीस

जवाबों:


86

आप 100% सही हैं। यह है नहीं राम को मुक्त करने के एक अच्छा अभ्यास। यह कार्गो पंथ प्रणाली प्रशासन का एक उदाहरण है।


9
कार्गो कल्चर सिस्टम एडमिनिस्ट्रेशन का उल्लेख करने के लिए +1। कोई भी व्यक्ति जो उस शब्द को नहीं जानता है और इसका मतलब क्या निकाल दिया जाना चाहिए।
Tonny

8
@ टोनी: हम तब बिना
सिस्मिन

2
अधिकांश मानवता की तरह, मुझे बहुत से अनुमोदन के साथ ब्राइट एशेज़ों से प्यार है, लेकिन एक हवाला या तर्क मेरे सुपरिगो +1 को अर्जित करता है।
हारून हॉल

2
यदि आप बुरा नहीं मानते हैं, तो कार्गो-पंथ प्रशासन, और साथ ही ऊपर बताएं। शायद एक फॉलो-ऑन एडिट में? मैं अभी भी अपने +1 को रोक रहा हूं ...: पी
आरोन हॉल

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

62

हां, कैश साफ़ करने से RAM मुक्त हो जाएगी, लेकिन यह कर्नेल को कैश की बजाय डिस्क पर फ़ाइलों की तलाश करने का कारण बनता है जो प्रदर्शन के मुद्दों का कारण बन सकता है।

आम तौर पर जब उपलब्ध रैम कम हो जाती है तो कर्नेल कैश को साफ कर देगा। यह अक्सर pdflush का उपयोग करके डिस्क पर डस्टीटेड कंटेंट लिखता है।


20
+1 यह समझाने के लिए कि यह एक बुरा विचार क्यों है।
ओगरे Psalm33

35

इस तरह से कैश छोड़ने का कारण बेंचमार्किंग डिस्क प्रदर्शन के लिए है, और एकमात्र कारण यह मौजूद है।

I / O- गहन बेंचमार्क चलाते समय, आप यह सुनिश्चित करना चाहते हैं कि आपके द्वारा आज़माई गई विभिन्न सेटिंग्स वास्तव में डिस्क I / O कर रही हैं, इसलिए लिनक्स आपको पूर्ण रीबूट करने के बजाय कैश छोड़ने की अनुमति देता है।

प्रलेखन से उद्धृत करने के लिए :

यह फ़ाइल विभिन्न कर्नेल कैश (इनोड, डेंट्री, पेजकेक, आदि ...) के विकास को नियंत्रित करने का साधन नहीं है। ये ऑब्जेक्ट कर्नेल द्वारा स्वचालित रूप से पुनः प्राप्त हो जाते हैं जब सिस्टम पर कहीं और मेमोरी की आवश्यकता होती है।

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


बेशक, आप जो करने की कोशिश कर रहे हैं, उसके आधार पर, यहां तक ​​कि एक पूर्ण रीबूट भी डिस्क कैश को पर्याप्त रूप से साफ़ नहीं कर सकता है।
सीवीएन

1
"इन वस्तुओं को स्वचालित रूप से कर्नेल द्वारा पुनर्प्राप्त किया जाता है जब मेमोरी की आवश्यकता होती है" डिजाइन लक्ष्य है लेकिन यह हमेशा वास्तविक व्यवहार नहीं हो सकता है।
दान प्रीत

@DanPritts क्या वास्तव में आपको लगता है कि ऐसा नहीं है?
जो

2
स्पष्ट मामला तब है जब आप अधिक (गैर-ट्रंसपेरेंट) विशालपदों के आवंटन की अनुमति देने के लिए रैम को खाली करना चाहते हैं; एक और मामला पारदर्शी विशाल पृष्ठ कचरा संग्रह पॉज़ बग है (इस प्रश्न पर कहीं और मेरा उत्तर / टिप्पणी देखें)। लेकिन मेरी टिप्पणी सामान्य मामले के लिए थी। कभी-कभी सिस्टम को संचालित करने वाले लोग इसे डिजाइन / लागू करने वाले लोगों से बेहतर जानते हैं। अक्सर, नहीं - यही उनकी टिप्पणी के खिलाफ की रक्षा करने की कोशिश कर रहा है। मुझे बस खुशी है कि
दान Pritts

26

यहां मूल विचार शायद उतना बुरा नहीं है (सिर्फ बहुत भोला और भ्रामक): कैश्ड होने वाली फाइलें हो सकती हैं, जो कि निकट भविष्य में एक्सेस होने की संभावना नहीं है, उदाहरण के लिए लॉगफाइल्स। ये "खाओ" राम, जिसे बाद में ओएस द्वारा एक या दूसरे तरीके से आवश्यक होने पर मुक्त किया जाएगा।

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

मेरे वातावरण में, लिनक्स बहुत बार गलत अनुमान लगाता है, और अधिकांश यूरोपीय स्टॉक एक्सचेंज (लगभग 0900 स्थानीय समय) सर्वरों की शुरुआत में वे चीजें करना शुरू कर देंगे जो वे प्रति दिन केवल एक बार करते हैं, जो कि पहले से स्वैप की गई मेमोरी में स्वैप करने की आवश्यकता होती है क्योंकि लेखन logfiles, उन्हें संपीड़ित करना, उन्हें कॉपी करना आदि कैश को उस बिंदु तक भर रहे थे जहां चीजों को स्वैप करना था।

लेकिन क्या गिरना इस समस्या का हल है? निश्चित रूप से नहीं। यहाँ समाधान क्या होगा, यह बताने के लिए कि यह क्या पता नहीं है: कि इन फ़ाइलों का अब उपयोग नहीं किया जाएगा। यह लेखन एप्लिकेशन द्वारा किया जा सकता है जैसे posix_fadvise()कि सीएमडी लाइन टूल जैसी चीजों का उपयोग करके या vmtouch( जैसे कि चीजों के साथ-साथ कैश फ़ाइलों का उपयोग करने के लिए भी किया जा सकता है)।

इस तरह से आप उन डेटा को हटा सकते हैं जो अब कैश से आवश्यक नहीं हैं, और जो सामान कैश किया जाना चाहिए, उसे रखें, क्योंकि जब आप सभी कैश को छोड़ देते हैं, तो डिस्क से बहुत सारा सामान फिर से भरना पड़ता है। और यह सबसे खराब संभव क्षण में: जब इसकी आवश्यकता होती है; आपके आवेदन में देरी का कारण जो ध्यान देने योग्य है और अक्सर अस्वीकार्य है।

आपके पास जो जगह होनी चाहिए वह एक प्रणाली है जो आपके मेमोरी उपयोग पैटर्न (जैसे कि कुछ स्वैपिंग है) की निगरानी करती है और फिर उसी के अनुसार विश्लेषण करती है, और उसके अनुसार कार्य करती है। समाधान दिन के अंत में vtouch का उपयोग करके कुछ बड़ी फ़ाइलों को बेदखल करने के लिए हो सकता है; यह अधिक राम जोड़ने के लिए भी हो सकता है क्योंकि सर्वर का दैनिक शिखर उपयोग बस यही है।


मेरे सर्वर पर सभी ऐप्स nohup पर चल रहे हैं। शायद nohup.out कैश किया जा रहा है और स्मृति खा रहा है?
ivcode

@ivcode: यह एक कारण हो सकता है, जाँच करें कि कितना बड़ा nohup.out है। शायद यह कितना कैश है यह पता लगाने के लिए vmtouch का उपयोग करें।
प्लाज्माएच

मेरे पास cat /dev/null > path/nohup.outहर 15 मिनट में क्रोन जॉब है क्योंकि nohup.out तेजी से बढ़ रहा है। शायद linux
nohup.out

5
@ivcode यदि आपको आउटपुट की आवश्यकता नहीं है तो nohupआपको इसे फिर से निर्देशित करना चाहिए /dev/null। ऐसा लगता है कि आपके पास कुछ बिंदुओं पर आपके सिस्टम पर काम करने वाले कुछ बहुत ही अनुभवहीन सिस्मिन थे। देखें stackoverflow.com/questions/10408816/... कैसे निर्देशित करने के लिए के लिए nohupके उत्पादन के लिए/dev/null
डेविड विल्किंस

हालांकि 15 मिनट के अंतराल में nohup.out को साफ कर दिया जाता है, अगर किसी कारण से ऐप्स प्रक्रिया को मार दिया गया, तो nohup.out स्वचालित रूप से किसी अन्य स्क्रिप्ट से बैकअप ले लिया जाएगा। मैंने vmtouch की कोशिश की। यह वास्तव में एक बहुत अच्छा उपकरण है
ivcode

16

मैंने वर्चुअल मशीनों का एक समूह शुरू करते समय ड्रॉप कैश को उपयोगी माना है। या कुछ और जो कुछ डेटाबेस सर्वर जैसे बड़े पृष्ठ का उपयोग करता है।

लिनक्स में बड़े पृष्ठों को अक्सर एक पेज में डालने के लिए 2MB सन्निहित भौतिक रैम खोजने के लिए रैम को डीफ़्रैग करने की आवश्यकता होती है। सभी फ़ाइल कैश को मुक्त करना इस प्रक्रिया को बहुत आसान बनाता है।

लेकिन मैं ज्यादातर अन्य जवाबों से सहमत हूं कि हर रात फ़ाइल कैश को छोड़ने का एक अच्छा कारण नहीं है।


1
मैं दूसरे आदेश की ओर इशारा करने के लिए उकसाया पूर्वाग्रह कैश छोड़ने के लिए प्रतिक्रियाएं हैं।
नूह स्परियर

1
इसके अलावा, उच्च-मेमोरी नोड्स (1 टीबी) पर एचपीसी अनुप्रयोगों में, कुछ बड़ी फ़ाइलों में पढ़ने से बड़ी मात्रा में मेमोरी खाली हो जाती है। क्योंकि कई HPC एप्लिकेशन सैकड़ों GB के मॉलॉक का प्रदर्शन करते हैं, सिस्टम घंटों तक स्टाल कर सकता है क्योंकि सिस्टम द्वारा कैश्ड मेमोरी "बॉर्डर" तक पहुँचने के बाद माइग्रेशन प्रक्रियाओं को छोटे-छोटे टुकड़ों में NUMA नोड्स में फल-फूल कर चला जाता है। इससे भी बदतर, आप कुछ भी नहीं कर सकते हैं उपयोगकर्ता को कैश से मुक्त करने के लिए सिस्टम को छल करने के अलावा सभी छोटे 2MB ब्लॉक को आवंटित कर सकते हैं, जो एक बार में जारी कर सकते हैं, विशाल डीफ़्रैग और एप्लिकेशन को सामान्य रूप से चला सकते हैं।
user1649948

+1 बड़े पृष्ठ बनाने के लिए कमांड ( sysctl -w vm.nr_hugepages=...) तब तक काम करने से मना कर देता है जब तक कि मैं पहली बार कैश (आर्क लिनक्स) नहीं छोड़ता।
अलेक्सांद्र डबिन्सकी

8

यह संभव है कि यह प्रणाली को स्थिर करने के तरीके के रूप में स्थापित किया गया था जब वास्तव में समस्या को खोजने के लिए कौशल या अनुभव के साथ कोई नहीं था।

संसाधनों को मुक्त करना

ड्रॉपिंग कैश अनिवार्य रूप से कुछ संसाधनों को मुक्त कर देगा, लेकिन इस प्रणाली को बनाने का एक साइड इफेक्ट है जो वास्तव में यह करने के लिए कठिन प्रयास कर रहा है। यदि सिस्टम स्वैप कर रहा है (डिस्क स्वैप विभाजन से पढ़ने और लिखने की कोशिश कर रहा है, जो वास्तव में सक्षम है) से तेज है तो समय-समय पर कैश को छोड़ना लक्षण को कम कर सकता है , लेकिन कारण को ठीक करने के लिए कुछ भी नहीं करता है

स्मृति क्या खा रही है?

आपको यह निर्धारित करना चाहिए कि बहुत सारे मेमोरी खपत का कारण क्या है जो ड्रॉपिंग कैश को काम करता है। यह खराब कॉन्फ़िगर की गई किसी भी संख्या या केवल गलत तरीके से उपयोग की जाने वाली सर्वर प्रक्रियाओं के कारण हो सकता है। उदाहरण के लिए, एक सर्वर पर मैंने मेमोरी उपयोग को अधिकतम देखा जब एक मैगेंटो वेबसाइट 15 मिनट के अंतराल में एक निश्चित संख्या में आगंतुकों तक पहुंची। यह समाप्त होने के कारण अपाचे को कई प्रक्रियाओं को एक साथ चलाने की अनुमति देने के लिए कॉन्फ़िगर किया गया है। बहुत सारी प्रक्रियाएँ, बहुत सारी मेमोरी का उपयोग करना (Magento एक जानवर है कभी-कभी) = स्वैपिंग।

जमीनी स्तर

बस यह मत समझो कि यह कुछ ऐसा है जो आवश्यक है। यह पता लगाने में सक्रिय रहें कि यह क्यों है, अगर इसे गलत है, तो इसे अक्षम करने की हिम्मत रखें और सिस्टम का निरीक्षण करें - जानें कि वास्तविक समस्या क्या है और इसे ठीक करें।


4

लिनक्स / m68k में वास्तव में एक कर्नेल बग होता है जो किस्वैप्ड पागल हो जाता है और 100% सीपीयू (50% अगर कुछ अन्य सीपीयू-बाउंड कार्य है, जैसे कि डेबियन बाइनरी पैकेज ऑटोबुलेर - वल्गो बिल्डड - पहले से ही चल रहा है) खा सकता है, जो (सबसे अधिक) समय का, हमेशा नहीं) इस विशेष कमांड को हर कुछ घंटों में चलाकर कम किया जाए।

कहा जा रहा है कि ... आपका सर्वर संभवतः एक m68k (अटारी, अमिगा, क्लासिक मैकिंटोश, VME, Q40 / Q60, Sun3) सिस्टम ;-) नहीं है;

इस मामले में, जिस व्यक्ति ने लाइनों में डाल दिया, उसने कुछ संदिग्ध या, सबसे अच्छी, पुरानी सलाह का पालन किया, या इस बारे में विचार प्राप्त किया कि कैसे रैम का गलत इस्तेमाल किया जाना चाहिए (आधुनिक सोच वास्तव में कहती है "फ्री रैम रैम बर्बाद हुई है" और कैशिंग का सुझाव देता है) , या "खोजा" कि यह "सुधार" [sic!] एक और समस्या कहीं और (और एक उचित निर्धारण के लिए खोज करने के लिए बहुत आलसी था)।


"एक कर्नेल बग जिसके कारण kswapd पागल हो जाता है" - यह कौन सा बग है?
बेन

@ इस धागे को देखें (यह संदेश और कुछ फॉलोवर , जिनमें से एक का अनुमान है कि यह कहाँ से आ सकता है)
mirabilos

1
मैं एक समान समस्या का अनुभव कर रहा हूं (हालांकि यह x86_64 है) और इस समय एकमात्र समाधान कैश सर्वरफ़ॉल्ट.
फ़र्नान्डो

2
@ फर्नांडो मेरे पास m68k बॉक्स पर "ड्रॉप कैश" क्रोनजॉब है और साथ ही
rab

3

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

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

इसलिए, भले ही मेरी धारणा सही हो, कैश-क्लीनिंग कुछ ऐसी चीज नहीं है जो समझ में आती है, बल्कि यह किसी ऐसे व्यक्ति द्वारा किया गया काम है जो प्राथमिक समस्या को ठीक करने के लिए सक्षम नहीं है।


3

मैं एक रात के क्रोन नौकरी में ऐसा करने का एक प्रशंसनीय कारण सोच सकता हूं।

एक बड़ी प्रणाली पर, यह समय-समय पर कैश छोड़ने के लिए उपयोगी हो सकता है ताकि आप स्मृति विखंडन को हटा सकें।

कर्नेल पारदर्शी विशालपृष्ठ समर्थन छोटे पृष्ठों को विशालपृष्ठों में समेटने के लिए मेमोरी का आवधिक रूप से व्यापक प्रवाह करता है। पतित परिस्थितियों में यह एक या दो मिनट के सिस्टम ठहराव में परिणाम कर सकता है (इसके साथ मेरा अनुभव RHEL6 में था; उम्मीद है कि इसमें सुधार हुआ है)। छोड़ने वाले कैश से विशाल पृष्ठ स्वीपर को काम करने के लिए कुछ जगह मिल सकती है।

आप यह तर्क दे सकते हैं कि पारदर्शी विशालताओं को निष्क्रिय करने का यह एक अच्छा कारण है; OTOH आपको विश्वास हो सकता है कि पारदर्शी विशालता से समग्र प्रदर्शन में सुधार के लायक है, और दिन में एक बार अपने कैश खोने की कीमत का भुगतान करने के लायक है।


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

मुझे नहीं पता कि वास्तव में कोई भी साफ्टवेयर ऐसा करता है या नहीं।


1
क्या आपके पास इसके लिए कोई स्रोत है? यह कुछ ऐसा लगता है जिसे कर्नेल में ठीक किया जाना चाहिए यदि यह ऐसा मुद्दा है।
गपरेंट

3
मेरे पास पारदर्शी विशालताओं के साथ ठहराव के साथ व्यक्तिगत अनुभव है। आरएचईएल 6, डेल आर 810, 4 सीपीयू, 64 जीबी रैम। पारदर्शी विशालताओं को अक्षम करना (ऐसा करने के लिए / proc फ़ाइल है) ने तुरंत रोकें ठीक कर दीं। मैंने उस समय कैश ड्रॉप तकनीक की कोशिश नहीं की; इसके बजाय मैंने गैर-पारदर्शी विशालपृष्ठों का उपयोग करने के लिए अपने जावा ऐप को फिर से कॉन्फ़िगर किया, और पारदर्शी विशालपृष्ठों को निष्क्रिय कर दिया। IIRC, हमने यह महसूस करने के लिए पर्याप्त स्थिति में देखा कि हम केवल प्रभावित लोग नहीं थे, और यह कि Red Hat इस मुद्दे के बारे में जानता था।
डैन प्रिट्स

हैलो डैन, मैं अपने सर्वर पर उसी व्यवहार को कसता हूं। मैं डेटा की एक बड़ी मात्रा के साथ काम करता हूं, और एक ही अजगर कार्यक्रम (पहले गणना समय के x2-3) के 10+ संगणना के बाद कठोर प्रदर्शन गिरता है। अगर मैं एक नज़र डालें, तो मेमोरी कैश का आकार बहुत बड़ा है, 100 + जीबी। और अगर मैं इस मेमोरी कैश को फ्लश करता हूं, और अपने कार्यक्रम को फिर से चलाता हूं, तो मुझे अपना प्रारंभिक गणना समय वापस मिल जाता है। क्या आपके पास इस घटना के बारे में बताने के लिए कोई दस्तावेज या जानकारी है? धन्यवाद।
एक्सल बोरजा

1
access.redhat.com/solutions/46111 इसका वर्णन करता है। आप यह देखने के लिए पारदर्शी विशालताओं को अक्षम कर सकते हैं कि आपके मामले में समस्या है या नहीं।
दान प्रीति

2

बस मेरे दो सेंट जोड़ने के लिए: सिस्टम बहुत अच्छी तरह से जानता है कि ये मेमोरी पेज कैश हैं, और जब कोई एप्लिकेशन मेमोरी के लिए पूछता है तो उतना ही गिर जाएगा।

एक प्रासंगिक सेटिंग है /proc/sys/vm/swappiness, जो मेमोरी कार्ड को छोड़ने या मेमोरी कार्ड पेज को "निष्क्रिय" करने के लिए पसंद करने के लिए नए मेमोरी आवंटन के दौरान कर्नेल को बताता है।


1

सवाल 2014 का है, लेकिन जैसा कि आज तक कुछ छिपे हुए सेंटोस 6.8 बैकेंड पर समस्या मौजूद है, यह अभी भी किसी के लिए उपयोगी हो सकता है।

https://github.com/zfsonlinux/zfs/issues/1548 zfs के साथ किसी समस्या का वर्णन करता है। वहां, डिस्क स्थान हटाई गई फ़ाइलों के लिए मुक्त नहीं किया गया है क्योंकि यदि nfs को zfs के शीर्ष पर उपयोग किया जाता है तो फ़ाइल के इनोड कर्नेल के इनोड कैश से नहीं गिराए जाते हैं।

बग थ्रेड से उद्धृत करने के लिए, Behlendorf, Jan 6 2015 ने लिखा:

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

यानी एक रात की गूंज 3> / proc / sys / vm / drop_caches उस बग के लिए सबसे आसान फिक्स है यदि आप अपने zfs को पुनर्गठन के लिए डाउनटाइम नहीं चाहते हैं।

तो शायद कार्गो पंथ प्रशंसा नहीं करते, लेकिन कुछ बहुत अच्छा डिबगिंग का कारण था।


0

यह NUMA (गैर समरूप मेमोरी एक्सेस) सिस्टम पर समझ में आ सकता है, जहां, आमतौर पर, प्रत्येक CPU (सॉकेट) सभी मेमोरी को पारदर्शी रूप से एक्सेस कर सकता है, लेकिन समानांतर एचपीसी अनुप्रयोगों के साथ इसकी अपनी मेमोरी को अन्य सॉकेट की मेमोरी की तुलना में तेजी से एक्सेस किया जा सकता है।

कई सरल समानांतर अनुप्रयोग एक प्रक्रिया से फ़ाइल I / O करने की प्रवृत्ति रखते हैं, इस प्रकार डिस्क कैश के लिए आवंटित एक एकल NUMA नोड पर मेमोरी के एक बड़े अंश से बाहर निकलते हैं, जबकि अन्य NUMA नोड पर मेमोरी ज्यादातर मुक्त हो सकती है। इन स्थितियों में, चूंकि लिनक्स कर्नेल में कैश रीक्लेमिंग प्रक्रिया, जहां तक ​​मुझे पता है, अभी भी NUMA- अवगत नहीं है, NUMA नोड पर चलने वाली प्रक्रियाएं जिन्हें कैश को मेमोरी आवंटित की गई है, उन्हें अन्य NDA नोड पर मेमोरी आवंटित करने के लिए मजबूर किया जाता है, जब तक अन्य नोड पर मुफ्त रैम है, इस प्रकार प्रदर्शन को मारना।

हालांकि, एचपीसी प्रणाली में, एक नए उपयोगकर्ता की नौकरी शुरू करने से पहले कैश को साफ करना समझदारी होगी, न कि क्रोन के साथ।

गैर समानांतर अनुप्रयोगों के लिए यह समस्या उत्पन्न होने की संभावना नहीं है।


0

जब आपका पृष्ठ कैश काफी बड़ा होता है (आपके वर्तमान स्वैप उपयोग की तुलना में बहुत बड़ा), और स्वैप और स्वैप आउट होता है, तो यह तब होता है जब आपको कैश छोड़ने की आवश्यकता होती है। मैंने ऐसे मामलों को देखा है जहां उबंटू 16.04LTS पर चलने वाले मेरे एक मारियाडीबी डेटाबेस सर्वर में मेमोरी उपयोग बढ़ जाता है, और लिनक्स ने अप्रयुक्त पृष्ठ कैश को हटाने के बजाय स्वैप उपयोग को बढ़ाने के लिए चुना है। मेरे सिस्टम में पहले से ही बहुत बड़ी ट्रांसपेरेंट अक्षमियां हैं क्योंकि TokuDB को इसे अक्षम करने की आवश्यकता थी। वैसे भी शायद यह बग नहीं है, लेकिन फिर भी इस व्यवहार को करने के लिए लिनक्स मुझे काफी हैरान कर रहा है। विभिन्न स्रोतों ने कहा कि जब आवेदन ने अनुरोध किया तो लिनक्स पेज कैश को हटा देगा:

लेकिन वास्तविकता इतनी सरल नहीं है। वर्कअराउंड या तो है:

  1. समय-समय पर कैश छोड़ें
  2. जरूरत पड़ने पर कैश छोड़ें (गतिविधियों की अदला-बदली के लिए vmstat 1 का उपयोग करके निगरानी करें)
  3. Dd या python-faditise जैसे यूटिलिटी का उपयोग करके कैश से कुछ फाइलों (जैसे अपाचे लॉग फाइल) को हटाने के लिए linux को सलाह दें। Https://unix.stackexchange.com/questions/36907/drop-a-specific-file-from-the-linux-filesystem-cache देखें

उदाहरण dd रन:

dd if=/var/log/apache2/access_log.1 iflag=nocache count=0

उदाहरण अजगर-सनक:

pyadvise -d /var/log/apache2/access_log.1


-5

मेरे पास एक डेस्कटॉप मशीन है जिसमें 16GB RAM PAE कर्नेल पर चलती है। एक या दो घंटे के बाद डिस्क प्रदर्शन नाटकीय रूप से कम हो जाता है जब तक मैं कैश नहीं छोड़ता, इसलिए मैंने इसे क्रोन में डाल दिया। मुझे नहीं पता कि यह पीएई कर्नेल के साथ एक समस्या है या कैश कार्यान्वयन इतना धीमा है अगर बहुत मेमोरी है।


9
यह "कार्गो पंथ" सिस्टम प्रशासन का एक प्रमुख उदाहरण है: समस्या का पता लगाने और हल करने के बजाय, आप बस इसे मास्क कर रहे हैं।
माइकल हैम्पटन

2
कभी-कभी समीचीन समाधान सही होता है। यह सिर्फ वास्तविक समस्या को हल करने में लगाया जा सकता है, या यह उतना ही समाधान हो सकता है जितना परिस्थितियों में आवश्यक है। यहां तक ​​कि अगर यह बुरा अभ्यास है, यह अभी भी "कार्गो पंथ नहीं है।" एक प्रदर्शित कारण और प्रभाव है: ड्रॉप कैश और डिस्क प्रदर्शन में सुधार होता है।
दान प्रीत

1
CCSA की मूल परिभाषा का एक हिस्सा गलती के लिए सहसंबंध की गलती की प्रवृत्ति थी, और यहाँ हम हैं। एक सहसंबद्ध लेकिन कार्य-कारण इकाई को संबोधित करके समस्या का समाधान करना उप-विषयक समस्या-समाधान है, जो कि सीसीएसए की अवधारणा के खिलाफ चेतावनी देने की कोशिश कर रहा है।
अंडरस्कोर_ड
हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.