2011-12-01 13 views
9

मैं यह जानने के लिए एक अच्छा सूत्र जानने की कोशिश कर रहा हूं कि कितनी मेमोरी उपलब्ध है। मैं वर्तमान में निम्नलिखित सूत्र का उपयोग कर रहा हूं: freeMem = MemFree + Buffers + Cached - Shmem। हालांकि, इस सूत्र के अनुसार मेरी एम्बेडेड प्रणाली स्मृति खो रही है। अब मैं सोच रहा हूं कि मेरे पास मेमोरी लीक है इसलिए मैंने कर्नेल में kmemleak को सक्षम किया। mpatrol के अनुसार, valgrind, और coverity मेरे पास उपयोगकर्ता की जगह में कोई रिसाव नहीं है। क्या कर्नेल स्पेस में कोई रिसाव है या मेरा फॉर्मूला बंद है? ध्यान दें कि मेरे पास इस डिवाइस के लिए कोई स्वैप नहीं है।लिनक्स कुल उपलब्ध स्मृति

MYBOX> cat /proc/meminfo 
MemTotal:  2073348 kB 
MemFree:   1388180 kB 
Buffers:   137016 kB 
Cached:   88772 kB 
SwapCached:   0 kB 
Active:   589124 kB 
Inactive:   44380 kB 
Active(anon):  410236 kB 
Inactive(anon):  1992 kB 
Active(file):  178888 kB 
Inactive(file): 42388 kB 
Unevictable:   0 kB 
Mlocked:    0 kB 
HighTotal:  1310716 kB 
HighFree:   811828 kB 
LowTotal:   762632 kB 
LowFree:   576352 kB 
SwapTotal:    0 kB 
SwapFree:    0 kB 
Dirty:    64 kB 
Writeback:    0 kB 
AnonPages:  407712 kB 
Mapped:   26140 kB 
Shmem:    4516 kB 
Slab:    40408 kB 
SReclaimable:  8320 kB 
SUnreclaim:  32088 kB 
KernelStack:  1480 kB 
PageTables:   1464 kB 
NFS_Unstable:   0 kB 
Bounce:    0 kB 
WritebackTmp:   0 kB 
CommitLimit:  1036672 kB 
Committed_AS:  660508 kB 
VmallocTotal:  237344 kB 
VmallocUsed:  104556 kB 
VmallocChunk:  126296 kB 

उत्तर

2

userland से लीक स्मृति /proc/meminfo में वैसे भी नहीं दिखाया जाएगा क्योंकि जहाँ तक गिरी का संबंध है यह स्मृति आवंटित (कोई फर्क नहीं पड़ता अगर आप नि: शुल्क का उपयोग करें() अपने userland अनुप्रयोग में है या नहीं, यह या तो साथ आवंटित है mmap() syscall या brk()/sbrk() और कर्नेल उपयोगकर्तालैंड में आवंटित पृष्ठों का ट्रैक रखता है, अन्यथा हम गंभीर समस्या में होंगे;)।

मुझे स्पष्ट रूप से समझ में नहीं आता कि आप अपनी धारणा के साथ कैसे आए हैं कि आप स्मृति लीक कर रहे हैं? यहां एक अच्छा लिंक redhat/meminfo है यदि आपने इसे पहले से नहीं पढ़ा है जो बताता है कि प्रत्येक आंकड़े वास्तव में क्या मतलब है।

+0

खैर मैं प्रणाली, जबकि यह एक दो सप्ताह की अवधि में बेकार था निगरानी कर रहा था। सिस्टम उस हफ्ते में लगभग 10 एमबी नीचे था - यह बहुत अधिक प्रतीत नहीं होता है लेकिन सिस्टम को रीबूट किए बिना वर्षों तक चलने की जरूरत है। मुझे पूरा यकीन है कि एप्लिकेशन साफ़ हैं लेकिन मैं उन ड्राइवरों के बारे में सोच रहा था जिनका मैं उपयोग कर रहा हूं। क्या/proc/meminfo मुझे पूरे सिस्टम उपयोगकर्ता और कर्नेल स्पेस नहीं दिखाएगा? – atomicbaum

+1

हाँ '/ proc/meminfo' पूरी चीज दिखाएगा, लेकिन आप लीक मेमोरी अनुमान लगाने के लिए इस से समीकरण नहीं बना सकते हैं। दूसरी ओर आप यह पता लगा सकते हैं कि अधिक से अधिक स्मृति का उपयोग किया जा रहा है, अगर आप यही कह रहे हैं। इस मामले में, अपना समीकरण बनाने की कोशिश करने के बजाय, आप यहां बताए गए 'free -m' कमांड का उपयोग कर सकते हैं: http://blog.scoutapp.com/articles/2010/01/11/free-memory-on -Linux-मुक्त एम-बनाम-proc-meminfo। यदि आप अभी भी उपलब्ध स्मृति को नीचे और नीचे देखते हैं तो निश्चित रूप से कुछ और अधिक मेमोरी खा रहा है (लेकिन जरूरी नहीं कि स्मृति लीक हो;) –

+0

मुझे नहीं पता कि मैंने पहले क्यों नहीं देखा ... स्रोत को देखते हुए "फ्री" कमांड के लिए ऐसा लगता है कि सूत्र "kb_main_free + kb_main_buffers + kb_main_cached" है और यह/proc/meminfo से आता है जो पकड़ता है ... (sysinfo.c और free.c को देख रहा है)। – atomicbaum

0

ऑक्सव के साथ सहमत - उपयोग/proc/meminfo शायद उपयोगकर्ता प्रक्रिया मेमोरी को ट्रैक करने का सबसे अच्छा तरीका नहीं है, क्योंकि इसमें सभी उपयोगकर्ता प्रक्रियाओं द्वारा आवंटित स्मृति शामिल है जिससे आपकी प्रक्रिया की खपत को कम करना मुश्किल हो जाता है।

आपकी प्रक्रिया द्वारा खपत कुल स्मृति को ट्रैक करने का एक बेहतर तरीका top (1) का उपयोग करना होगा और वीआईआरटी (जिसमें मेमोरी स्वैप आउट शामिल है) या आरईएस (जिसमें केवल भौतिक स्मृति शामिल है) देखें।

लेकिन आप का उपयोग करने के/proc/meminfo तो सूत्र मैं का प्रयोग करेंगे होगा चाहते हैं यदि:

MemTotal = MemFree + कैश्ड + बफ़र + SwapCached

... कृपया ध्यान दें कि यह केवल डेटा के लिए खाता है, कोड नहीं। MemTotal के अधिकांश - (समीकरण के दाईं ओर मात्रा) आपकी कर्नेल छवि होना चाहिए।

+0

ऐसा नहीं है कि _it सबसे अच्छा तरीका नहीं है, कर्नेल पीओवी से उपयोगकर्तालैंड में मेमोरी रिसाव को ट्रैक करना असंभव है। उपयोगकर्तालैंड एप्लिकेशन से एक रिसाव तब होता है जब आप किसी भी सूचक को हाथ से पहले() को कॉल किए बिना स्मृति क्षेत्र का संदर्भ देते हैं। लेकिन कर्नेल के लिए, इस स्मृति को अभी भी प्रयुक्त स्मृति के रूप में संदर्भित किया जाता है और फिर प्रयुक्त स्मृति के रूप में दिखाई देगा (यानी ओपी के समीकरण में छेद के रूप में नहीं दिख रहा है)। आईएमएचओ '/ proc/meminfo' लीक मेमोरी के बारे में कुछ भी नहीं बताता है। आप वास्तव में लीक मेमोरी को शीर्ष के साथ अनुमानित नहीं कर सकते हैं क्योंकि लीक मेमोरी नियमित वीआईआरटी मेम के रूप में दिखाई देगी। (फिर समीकरण में कोई छेद नहीं) –

+0

क्षमा करें कि टिप्पणी बहुत लंबी थी ... हालांकि मैं आपसे सहमत हूं कि ओपी का छेद , जो (गलत तरीके से) लीक मेमोरी के रूप में व्याख्या की गई है, ज्यादातर कर्नेल छवि कोड और कुछ अन्य कुछ बिट्स कर्नेल द्वारा आरक्षित हैं (मेरे उत्तर पर दिए गए लिंक पर समझाया गया है)। –

+0

सिस्टम में कोई स्वैप नहीं है, लेकिन मैं जानना चाहता हूं कि पूरे सिस्टम के लिए कितनी मेमोरी उपलब्ध है। मुझे यकीन नहीं है कि "डेटा के लिए केवल खाते हैं, कोड नहीं" का मतलब क्या है। क्या आप राम में लोड किए गए कार्यक्रमों के बारे में बात कर रहे हैं? – atomicbaum

1

आपकी "फ्री मेमोरी" गणना में एक चीज़ गुम है - इसे SReclaimable (पुनः प्राप्त करने योग्य स्लैब कैश के लिए) प्रभावी ढंग से मुक्त मेमोरी में जोड़ना चाहिए।

यदि यह समय के साथ प्रभावी रूप से मुक्त स्मृति में धीमी कमी को नहीं बदलता है, तो आपको नियमित अंतराल पर /proc/meminfo का स्नैपशॉट लेना चाहिए और यह पहचानना चाहिए कि कौन सी रेखा में वृद्धि दिखाई देती है।

यदि यह SUnreclaim लाइन बढ़ रही है, तो आप अपने कर्नेल स्लैब उपयोग को देखने और अपराधी की पहचान करने के लिए /proc/slabinfo देख सकते हैं। यह संभव है कि यह केवल स्मृति विखंडन है जिसे आप देख रहे हैं, और अंत में यह लंबे समय तक समाप्त हो जाएगा।

+0

पुन: बसने, क्या आप कह रहे हैं कि एक बढ़ती हुई SUNreclaim राशि ठीक है?या कभी-कभी ठीक है, ज्यादातर खराब, या हमेशा बुरा। मेरे पास बढ़ते SUNreclaim के साथ एक उपकरण है, जो 60% भौतिक राम तक पहुंच गया है। और ताज़ा बूट सिस्टम पर काम करने वाले कार्य काम करने में असफल होते हैं (और ओओएम हत्यारा और रीबूट को ट्रिगर करते हैं) जब सुनरेक्लेम ने उच्च प्राप्त किया है। (इस मान के बारे में अधिक जानकारी प्राप्त करना बहुत मुश्किल है) –

+0

@ करलप: यह पूरी तरह से संदर्भ पर निर्भर है, जैसे कि बड़ी संख्या में उपयोगकर्ता स्पेस स्मृति अच्छी तरह से एक अच्छी या बुरी चीज नहीं है। अगर आपको किसी और चीज के लिए स्मृति की आवश्यकता है (और ऐसा लगता है कि आप ऐसा करते हैं), तो शायद आप स्लैब कैश द्वारा * क्यों * उपभोग की जा रही है, पहचानना चाहते हैं - पहले चरण के रूप में '/ proc/slabinfo' जांचें। – caf

0

मेरे सिस्टम के लिए मैं कितना स्मृति सेवन किया जाता है की जाँच करने के लिए निम्न आदेश का उपयोग कर रहा:

ps aux | awk '{sum +=$4}' 

यह वर्तमान में चल रहे सभी प्रक्रियाओं के लिए इस्तेमाल किया स्मृति का कुल प्रतिशत कहते हैं।

0

फ्रीमेम = मेमफ्री + बफर + कैश किए गए - मैप किए गए, कैश्ड मेमोरी में मैप किए गए भाग होते हैं, इस भाग को उपयोगकर्ता स्थान पर मैप किया गया है।

0

पहले यह मेमफ्री + कैच किया गया था (जो कई सालों पहले सही है)।

अब यह मेमफ़्री + सक्रिय (फ़ाइल) + निष्क्रिय (फ़ाइल) + SRreclaimable है।

आगे के संदर्भ के लिए LINUX TORVALD द्वारा नीचे दिए गए लिंक को कम करें।

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=34e431b0ae398fc54ea69ff85ec700722c9da773

संबंधित मुद्दे