Warum zeigen der Befehl "free" und "dmidecode" unterschiedliche Werte für RAM an?

Ich habe einen CentOS 5.10 ( 32-Bit ) Server auf VMWare. Es sind 4 GB RAM zugewiesen.

Wenn ich renne, dmidecode -t 17 | grep Size | grep MBsehe ich:

Size: 4096 MB

Doch wenn ich renne free, sehe ich:

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

Warum besteht eine Diskrepanz zwischen der Gesamtzahl der Speicherberichte freeund der dmidecodeAusgabe?

Der Kernel, den ich verwende, ist:

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

Zugegeben, der Kernel läuft nicht, PAEaber ich dachte, das wäre nur für Speicher mit mehr als 4 GB erforderlich .

Ich weiß, dass mir etwas Einfaches fehlt - kann jemand bitte näher darauf eingehen?

Zusätzliche Anmerkungen / Bemerkungen

Es sieht definitiv so aus, als würde mein Kernel eine Menge Speicher für andere Dinge reservieren. Folgendes sehe ich in /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

— Mike B.
quelle

Antworten:

Mit einem 32-Bit-Kernel stehen nur 4 GB Adressraum zur Verfügung . Ein Teil dieses Adressraums muss von der (virtuellen oder physischen) Hardware im System, wie z. B. Grafikkarten, Netzwerkkarten usw., für eigene Zwecke verwendet werden. Diese Nutzung liegt normalerweise zwischen 256 MB und 1 GB, je nachdem, wie viel Adressraum die jeweilige Hardware benötigt.

Da dieser Adressraum von der Hardware verwendet wird, ist der entsprechende RAM für ein 32-Bit-System im Allgemeinen nicht zugänglich.

Sie haben mehrere Möglichkeiten:

Die bevorzugte Option ist das Ausführen eines 64-Bit-Betriebssystems. Dadurch wird der Adressraum erheblich erweitert, sodass ausreichend Platz für RAM und Hardware vorhanden ist. Außerdem wird das 32-Bit-Limit von 2 GB / 3 GB für Anwendungen überschritten, während 32-Bit-Programme weiterhin ausgeführt werden können. Im Allgemeinen sollte auf jedem System mit 2 GB mehr RAM ein 64-Bit-Betriebssystem ausgeführt werden, um diese Probleme zu vermeiden.
Eine andere Möglichkeit besteht darin, einen 32-Bit-Kernel mit aktiviertem PAE auszuführen. Dadurch wird der Arbeitsspeicher ausgeblendet, aber jeder Prozess ist abhängig von den Details des Kernel-Builds weiterhin auf 2 GB / 3 GB Adressraum beschränkt. Da 64-Bit-Betriebssysteme 32-Bit-Anwendungen einwandfrei ausführen, hat dies keinen Vorteil und viele Nachteile (z. B. das Fehlen eines Upgrade-Pfads).

— Michael Hampton
quelle

Vielen Dank. Das ist sinnvoll, aber wie kann ich genau überprüfen, wie viel von Hardware für andere Zwecke "versteckt" / verbraucht wird? Wäre das unter /proc/meminfo?

— Mike B

@MikeB Insbesondere bin ich mir nicht sicher, obwohl es offensichtlich ist, dass irgendwo etwa 800 MB verloren gehen.

— Michael Hampton

Für den Zweck meiner ersten Frage denke ich, dass sie beantwortet wurde, aber die nächste Frage lautet "WARUM?". Es sieht so aus, als gäbe es einen anderen Thread, der dies abdeckt ( unix.stackexchange.com/questions/97261/… ), also werde ich versuchen, etwas mehr zu graben und möglicherweise später Fragen haben. Vielen Dank!

— Mike B

Als professionelle Systemadministratoren kümmern wir uns darum, aber nur bis zu einem gewissen Punkt - wo und wie sich dies auf den Betrieb auswirkt. Ich glaube, ich habe diesen Aspekt angesprochen.

— Michael Hampton

@MikeB /proc/iomemzeigt Ihnen den Speicher, der von Geräten verwendet wird, für die Linux einen Treiber hat. Die e820-Speicherzuordnung (ganz am Anfang dmesgeines frisch gestarteten Kernels) zeigt Ihnen, was Ihr BIOS / EFI davon hält, welche Regionen reserviert sind. AFAIK ist eine manuelle Aufgabe ohne Werkzeugunterstützung.

— Mihi

Die Ausgabe des freeBefehls zählt nicht den reservierten Kernelspeicher und einige andere kleine Bits. Sie werden diese Diskrepanz sogar in einem 64-Bit-Kernel und sogar mit <2 GB RAM sehen.

— John
quelle

Das sind nicht nur ein paar andere Kleinigkeiten ...

— Michael Hampton

Nun, nein, nicht buchstäblich Bits wie in 8-Bit-Make-a-Byte ... aber es sind höchstens ein paar zehn MB. Prozentual ist es sehr klein.

— John

In zwei 64-Bit-Systemen, auf denen RHEL 5.10 in VMware ausgeführt wird, zeigt ein "physischer" 2-GB-RAM-Computer insgesamt 2010 MB an free, ein 4-GB-Computer 3948 MB.

— John

Danke ... seltsam, dass ich eine so große Diskrepanz in meiner sehe, aber es klingt so, als ob das "normal" sein könnte.

— Mike B

Nein, das ist nicht "normal" - es sind mehr als 800 MB!

— Michael Hampton

Die kritische Zeile aus Ihrer physischen RAM-Karte ist folgende:

 BIOS-e820: 0000000100000000 - 0000000140000000 (usable)

Diese Zeile zeigt, dass 1 GB (0x40000000 Byte, hexadezimal) des physischen RAM Ihres Systems vom BIOS oberhalb der 4-GB-Grenze zugeordnet wird, sodass ein 32-Bit-System ohne PAE nicht darauf zugreifen kann.

— Dämmerung -inaktiv-
quelle