जब मेमोरी की मांग बढ़ जाती है तो लिनक्स बड़ी डिस्क कैश को मुक्त नहीं करता है


24

एक 2.6.31-302 x86-64 कर्नेल पर उबंटू चलाना। समग्र समस्या यह है कि मेरे पास 'कैश्ड' श्रेणी में स्मृति है जो ऊपर जाती रहती है और जब हमारे आवेदन को इसकी आवश्यकता होती है तब भी इसे मुक्त या उपयोग नहीं किया जाएगा।

तो यहाँ 'फ्री' कमांड से जो मिलता है। इसमें से कोई भी पहली नज़र में साधारण नहीं दिखता।

# free
             total       used       free     shared    buffers     cached
Mem:       7358492    5750320    1608172          0       7848    1443820
-/+ buffers/cache:    4298652    3059840
Swap:            0          0          0

पहली बात जो किसी को कहने वाली है, "चिंता न करें, लिनक्स उस मेमोरी को स्वचालित रूप से प्रबंधित करता है।" हां, मुझे पता है कि मेमोरी मैनेजर को कैसे काम करना चाहिए; समस्या यह है कि यह सही काम नहीं कर रहा है। यहां "कैशेड" 1.4 जीबी आरक्षित और अनुपयोगी प्रतीत होता है।

लिनक्स के बारे में मेरा ज्ञान बताता है कि 3 जीबी "फ्री" है; लेकिन सिस्टम का व्यवहार अन्यथा कहता है। जब पीक उपयोग के दौरान 1.6 जीबी वास्तविक फ्री मेमोरी का उपयोग किया जाता है, जैसे ही अधिक मेमोरी की मांग की जाती है (और पहले कॉलम में 'फ्री' 0 पर पहुंच जाता है) ओओएम किलर को आमंत्रित किया जाता है, प्रक्रियाएं मार दी जाती हैं, और समस्याएं पैदा होती हैं भले ही '/' में 'फ्री' / / बफ़र्स / कैश पंक्ति में अभी भी लगभग 1.4 जीबी 'फ्री' है।

मैंने प्रमुख प्रक्रियाओं पर oom_adj मानों को ट्यून किया है ताकि यह सिस्टम को अपने घुटनों पर न लाए, लेकिन फिर भी महत्वपूर्ण प्रक्रियाओं को मार दिया जाएगा, और हम कभी भी उस बिंदु तक नहीं पहुंचना चाहते हैं। विशेष रूप से तब, जब सैद्धांतिक रूप से, 1.4GB अभी भी "मुक्त" है यदि यह केवल डिस्क कैश को बाहर निकाल देगा।

किसी को भी यहाँ क्या हो रहा है किसी भी विचार है? लिनक्स के 'फ्री' कमांड और "मेरे पास कोई मुफ्त मेमोरी क्यों नहीं है" के बारे में गूंगे सवालों से इंटरनेट भर गया है और इस वजह से मुझे इस मुद्दे पर कुछ भी नहीं मिल रहा है।

पहली चीज जो मेरे सिर में आती है, वह है अदला-बदली। हमारे पास एक sysadmin है जो इसके बारे में अडिग है; यदि वे बैकअप लेते हैं तो मैं स्पष्टीकरण के लिए खुला हूं। क्या इससे समस्याएँ हो सकती हैं?

यहां चलाने के बाद मुफ्त है echo 3 > /proc/sys/vm/drop_caches:

# free
             total       used       free     shared    buffers     cached
Mem:       7358492    5731688    1626804          0        524    1406000
-/+ buffers/cache:    4325164    3033328
Swap:            0          0          0

जैसा कि आप देख सकते हैं, कैश की कुछ मामूली मात्रा वास्तव में मुक्त हो गई है, लेकिन लगभग 1.4 जीबी "अटक" लगता है। दूसरी समस्या यह है कि यह मूल्य समय के साथ बढ़ने लगता है। एक अन्य सर्वर पर 2.0 जीबी अटक गया है।

मैं वास्तव में इस मेमोरी को वापस चाहूंगा ... किसी भी मदद की सबसे अधिक सराहना की जाएगी।

यहाँ है cat /proc/meminfoअगर यह कुछ भी लायक है:

# cat /proc/meminfo 
MemTotal:        7358492 kB
MemFree:         1472180 kB
Buffers:            5328 kB
Cached:          1435456 kB
SwapCached:            0 kB
Active:          5524644 kB
Inactive:          41380 kB
Active(anon):    5492108 kB
Inactive(anon):        0 kB
Active(file):      32536 kB
Inactive(file):    41380 kB
Unevictable:           0 kB
Mlocked:               0 kB
SwapTotal:             0 kB
SwapFree:              0 kB
Dirty:               320 kB
Writeback:             0 kB
AnonPages:       4125252 kB
Mapped:            42536 kB
Slab:              29432 kB
SReclaimable:      13872 kB
SUnreclaim:        15560 kB
PageTables:            0 kB
NFS_Unstable:          0 kB
Bounce:                0 kB
WritebackTmp:          0 kB
CommitLimit:     3679244 kB
Committed_AS:    7223012 kB
VmallocTotal:   34359738367 kB
VmallocUsed:        7696 kB
VmallocChunk:   34359729675 kB
DirectMap4k:     7340032 kB
DirectMap2M:           0 kB

3
मुझे आपके कैश के लिए कोई स्पष्टीकरण नहीं है (हालांकि मुझे संदेह है कि mmap'd फाइलें शायद इसमें आती हैं), लेकिन मानवता की भलाई के लिए, एक फावड़ा और कुछ क्विकटाइम लें और "आपको स्वैप की आवश्यकता नहीं है" से छुटकारा पाएं अगर आपके पास बहुत सारी रैम है! " बूस्टर। वे तर्कसंगत चर्चा के लिए प्रतिरक्षा हैं, और वे खतरनाक रूप से गलत हैं। तथ्य यह है कि ओओएम हत्यारा आपको घूर रहा है, इसका सिर्फ एक लक्षण है।
Womble

मेरे विचार से भी। सलाह के लिए धन्यवाद। क्या आप कोई अन्य अच्छे लेख या तर्क जानते हैं कि स्वैप क्यों आवश्यक है?
ट्रिसवेब

6
क्योंकि अगर आपके पास स्वैप नहीं है, तो इस तरह की चीजें होती हैं। लेकिन अपने स्वैप डेनियर के साथ बहस करने की कोशिश मत करो; या तो क्विकटाइम तोड़ दें या "यदि आप यहां पर स्वैप नहीं करना चाहते हैं, तो आप इस गंदगी को ठीक करते हैं जिसे आपने बनाने पर जोर दिया है"। वे या तो अंततः अपने मन को बदल देंगे या वे कोशिश करके मर जाएंगे। किसी भी तरह से समस्या हल हो गई।
Womble

उत्कृष्ट, सुझावों के लिए धन्यवाद। आप mmap'd फाइलों के बारे में वैसे ही सही थे - एक त्वरित lsof ने लॉग फाइल की गिग्स को मेमोरी में दिखाया। उन्हें हटाकर मामले को सुलझाया गया।
Trisweb

समस्या यह है कि स्वैप के बिना, ओओएम किलर रनिंग में ओवरकमिटेटिंग परिणाम और प्रक्रियाओं को लॉन्च करने वाले सिस्टम में परिणामों को ओवरकॉम्पटिंग नहीं करना। रैम का प्रभावी उपयोग करने के लिए आपको स्वैप की आवश्यकता है।
डेविड श्वार्ट्ज

जवाबों:


8

मैंने अपने स्वयं के प्रश्न का उत्तर खोज लिया है - वूमल की मदद के लिए धन्यवाद (यदि आपको पसंद है तो एक उत्तर सबमिट करें)।

lsof -s उपयोग में फ़ाइल हैंडल दिखाता है, और पता चलता है कि कई गीगाबाइट्स थे mmap'd लॉग फाइलें कैश ले रही हैं।

एक लोगो को लागू करने से समस्या पूरी तरह से हल हो जानी चाहिए और मुझे अधिक मेमोरी का लाभ उठाने की अनुमति देनी चाहिए।

मैं स्वैप को फिर से सक्षम करूंगा ताकि हमें भविष्य में OOM किलर से कोई समस्या न हो। धन्यवाद।


2
mmap'd पृष्ठ अस्वीकार्य हैं, जिससे कैश को पिन नहीं करना चाहिए। क्या आप रामफ्स का उपयोग कर रहे हैं?
Psusi

नमस्ते, एक पुराने धागे को खोदने के लिए खेद है, लेकिन मैं वर्तमान में उसी मुद्दे का सामना कर रहा हूं और lsof -sकोई असामान्य उपयोग नहीं दिखाता हूं । हालाँकि, मैं आपके द्वारा कहा गया एक रम्फ का उपयोग कर रहा हूँ [और २.६.१० कर्नेल, जिसमें drop_caches सुविधा नहीं है]। आपको क्या लगता है कि संभावना संदिग्ध है?
राम

1
पारितोषिक के लिए धन्यवाद! अब मैं lsof -s | sort -rnk 7 | lessअपने टूलबॉक्स में जोड़ रहा हूँ । अन्य पाठकों के लिए एक नोट: यह बड़ी प्रविष्टियों की तरह हो सकता है /proc/net/rpc/nfs4.nametoid/channel, लेकिन वे मेरे मामले में अपराधी नहीं बने।
निकोलय

सुनिश्चित करें कि आपकी बड़ी फ़ाइलें या प्रोग्राम mlock का उपयोग नहीं कर रहे हैं। में /proc/meminfo"Unevictable" पृष्ठों पर नज़र।
माइकल मार्टिनेज

हमारी साइट का प्रयोग करके, आप स्वीकार करते हैं कि आपने हमारी Cookie Policy और निजता नीति को पढ़ और समझा लिया है।
Licensed under cc by-sa 3.0 with attribution required.