RAM के लिए "फ्री" कमांड और "dmidecode" अलग-अलग मान क्यों दिखाता है?

मुझे VMWare पर चलने वाला CentOS 5.10 ( 32-बिट ) सर्वर मिला है । इसे 4 जीबी रैम आवंटित किया गया है।

अगर मैं दौड़ता dmidecode -t 17 | grep Size | grep MBहूँ तो देखता हूँ:

Size: 4096 MB

फिर भी जब मैं दौड़ता freeहूं, तो देखता हूं:

             total       used       free     shared    buffers     cached
Mem:       3107140    1239244    1867896          0        332     400464
-/+ buffers/cache:     838448    2268692
Swap:      2096472          0    2096472

स्मृति freeरिपोर्ट और dmidecodeआउटपुट की कुल राशि के बीच एक विसंगति क्यों है ?

मैं जो कर्नेल चला रहा हूं वह है:

2.6.18-371.4.1.el5 #1 SMP Thu Jan 30 06:09:24 EST 2014 i686 i686 i386 GNU/Linux

बेशक, कर्नेल नहीं चल रहा है PAEलेकिन मुझे लगा कि यह केवल 4 जीबी से अधिक की मेमोरी के लिए आवश्यक है ।

मुझे पता है कि मैं कुछ सरल याद कर रहा हूं - क्या कोई कृपया विस्तृत कर सकता है?

अतिरिक्त नोट्स / अवलोकन

यह निश्चित रूप से लग रहा है कि मेरी गिरी अन्य सामान के लिए स्मृति का एक गुच्छा जला रही है। यहाँ मैं देख रहा हूँ /var/log/dmesg:

Linux version 2.6.18-371.4.1.el5 (mockbuild@builder17.centos.org) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-54)) #1 SMP Thu Jan 30 06:09:24 EST 2014
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000010000 - 000000000009f800 (usable)
 BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000ca000 - 00000000000cc000 (reserved)
 BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 00000000bfef0000 (usable)
 BIOS-e820: 00000000bfef0000 - 00000000bfeff000 (ACPI data)
 BIOS-e820: 00000000bfeff000 - 00000000bff00000 (ACPI NVS)
 BIOS-e820: 00000000bff00000 - 00000000c0000000 (usable)
 BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
 BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
 BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
 BIOS-e820: 00000000fffe0000 - 0000000100000000 (reserved)
 BIOS-e820: 0000000100000000 - 0000000140000000 (usable)
Warning only 4GB will be used.
Use a PAE enabled kernel.
3200MB HIGHMEM available.
896MB LOWMEM available.
found SMP MP-table at 000f6bf0
Memory for crash kernel (0x0 to 0x0) notwithin permissible range

— माइक बी
स्रोत

जवाबों:

32-बिट कर्नेल के साथ, आपके पास केवल 4GB उपलब्ध पता स्थान है । इस एड्रेस स्पेस में से कुछ का उपयोग सिस्टम में (वर्चुअल या फिजिकल) हार्डवेयर द्वारा किया जाता है, जैसे कि वीडियो कार्ड, एनआईसी आदि, अपने स्वयं के प्रयोजनों के लिए। यह उपयोग आमतौर पर 256MB-1GB के बीच होता है जो इस बात पर निर्भर करता है कि किसी विशेष हार्डवेयर की कितनी जगह है।

चूंकि वह पता स्थान हार्डवेयर द्वारा उपयोग किया जाता है, इसलिए संबंधित रैम आमतौर पर 32-बिट सिस्टम के लिए दुर्गम होती है।

आपके पास विकल्पों की एक जोड़ी है:

पसंदीदा विकल्प 64-बिट ऑपरेटिंग सिस्टम को चलाना है। यह नाटकीय रूप से पता स्थान का विस्तार करता है, इसलिए सभी रैम और हार्डवेयर के लिए बहुत जगह है। यह 32-बिट प्रोग्राम चलाने की क्षमता को बनाए रखते हुए अनुप्रयोगों पर 2GB / 3GB 32-बिट सीमा को भी तोड़ता है। सामान्य तौर पर, इन मुद्दों से बचने के लिए 2GB अधिक रैम वाले किसी भी सिस्टम को 64-बिट OS चलाना चाहिए।
एक अन्य विकल्प पीएई सक्षम के साथ 32-बिट कर्नेल को चलाने के लिए है। यह रैम को अनहाइड कर देगा, लेकिन कर्नेल बिल्ड के विवरणों के आधार पर प्रत्येक प्रक्रिया अभी भी 2GB / 3GB एड्रेस स्पेस तक सीमित रहेगी। चूंकि 64-बिट ओएस 32-बिट अनुप्रयोगों को पूरी तरह से अच्छी तरह से चलाएगा, इसलिए इसका कोई लाभ नहीं है और कई नुकसान (जैसे कि अपग्रेड की कमी)।

— माइकल हैम्पटन
स्रोत

धन्यवाद। यह समझ में आता है, लेकिन मैं विशेष रूप से यह कैसे जांच सकता हूं कि अन्य उद्देश्यों के लिए हार्डवेयर द्वारा "छिपाया गया" / उपभोग किया गया है? के तहत होगा /proc/meminfo?

— माइक बी

@ माइक विशेष रूप से, मुझे यकीन नहीं हो रहा है, हालांकि यह स्पष्ट है कि लगभग 800 एमबी खो गया है।

— माइकल हैम्पटन

मेरे प्रारंभिक प्रश्न के उद्देश्य के लिए, मुझे लगता है कि इसका उत्तर दिया गया है लेकिन अगला प्रश्न "क्यों?" है। ऐसा लगता है कि इसे कवर करने वाला एक और धागा है ( unix.stackexchange.com/questions/97261/… ) तो मैं कुछ और खुदाई करने की कोशिश करूंगा और बाद में सवाल हो सकता है। धन्यवाद!

— माइक बी

पेशेवर सिस्टम प्रशासक के रूप में, हम इस बारे में परवाह करते हैं, लेकिन केवल एक बिंदु तक - यह कहां और कैसे संचालन को प्रभावित करता है। मुझे लगता है कि मैंने उस पहलू को संबोधित किया है।

— माइकल हैम्पटन

@MikeB /proc/iomemआपको उन उपकरणों द्वारा उपयोग की जाने वाली मेमोरी दिखाएगा जहां लिनक्स के लिए ड्राइवर है। E820 मेमोरी मैप ( dmesgहौसले से बूट किए गए कर्नेल की शुरुआत में ) आपको दिखाएगा कि आपका BIOS / EFI क्या सोचता है कि कौन से क्षेत्र आरक्षित हैं। एक दूसरे के खिलाफ उनका मिलान AFAIK एक मैनुअल कार्य है जिसमें कोई उपकरण समर्थन नहीं है।

— मिही

freeकमांड का आउटपुट आरक्षित कर्नेल मेमोरी और कुछ अन्य छोटे बिट्स की गणना नहीं करता है। आप इस विसंगति को 64-बिट कर्नेल में और यहां तक कि <2GB RAM के साथ भी देखेंगे।

— जॉन
स्रोत

यह सिर्फ कुछ अन्य छोटे टुकड़े नहीं है ...

— माइकल हैम्पटन

ठीक है, नहीं, शाब्दिक रूप से 8-बिट्स-ए-बाइट के रूप में बिट्स नहीं ... लेकिन यह एमबी का केवल कुछ दसवां हिस्सा है। प्रतिशत-वार, यह बहुत छोटा है।

— जॉन

उदाहरण के लिए, वीएमवेयर के अंदर आरएचईएल 5.10 चलाने वाले दो 64-बिट सिस्टम में, एक 2 जीबी "भौतिक" रैम मशीन 2010 एमबी कुल में दिखाती है free, 4 जीबी मशीन 3948 एमबी दिखाती है।

— जॉन

धन्यवाद ... विचित्र है कि मैं इतनी बड़ी विसंगति देख रहा हूं, लेकिन ऐसा लगता है कि यह "सामान्य" हो सकता है।

— माइक बी।

नहीं, यह "सामान्य" नहीं है - यह 800+ एमबी है!

— माइकल हैम्पटन

आपके भौतिक RAM मानचित्र की महत्वपूर्ण रेखा यह है:

 BIOS-e820: 0000000100000000 - 0000000140000000 (usable)

यह रेखा दर्शाती है कि आपके सिस्टम की भौतिक RAM के 1 GB (0x40000000 बाइट्स, हेक्साडेसिमल) को 4GB सीमा से ऊपर BIOS द्वारा मैप किया जा रहा है, जो इसे PAE के बिना 32-बिट सिस्टम द्वारा दुर्गम बनाता है।

— डस्कवफ-सक्रिय
स्रोत