为什么“ free”命令和“ dmidecode”显示不同的RAM值？

我在VMWare上运行了CentOS 5.10（32位）服务器。它分配了4 GB的RAM。

如果我跑步，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 GB 时才需要。

我知道我缺少一些简单的东西-有人可以详细说明吗？

附加说明/观察

看起来我的内核肯定为其他东西保留了一堆内存。这是我在中看到的/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

— 迈克·B
source

Answers:

对于32位内核，您只有4GB的可用地址空间。系统中的（虚拟或物理）硬件（例如视频卡，NIC等）必须出于某些目的使用某些地址空间。这种用法通常在256MB-1GB之间，具体取决于特定硬件需要多少地址空间。

由于该地址空间由硬件使用，因此32位系统通常无法访问相应的RAM。

您有两种选择：

首选选项是运行64位操作系统。这极大地扩展了地址空间，因此所有RAM和硬件都有足够的空间。它还在保持运行32位程序能力的同时打破了2GB / 3GB 32位应用程序限制。通常，任何具有2GB以上RAM的系统都应运行64位OS以避免这些问题。
另一种选择是运行启用了PAE的32位内核。这将取消隐藏RAM，但是根据内核构建的具体情况，每个进程仍将限于2GB / 3GB的地址空间。由于64位操作系统可以很好地运行32位应用程序，因此这没有优点，也有很多缺点（例如缺少升级路径）。

— 迈克尔·汉普顿
source

谢谢。这是有道理的，但是我如何才能具体检查硬件为其他目的“隐藏” /消耗了多少？那会在下面/proc/meminfo吗？

— Mike B

@MikeB具体来说，虽然显然丢失了大约800 MB的内存，但我不确定该如何使用。

— 迈克尔·汉普顿

出于我的第一个问题的目的，我认为已经回答了，但是下一个问题是“为什么？”。似乎还有另一个线程覆盖了这个问题（unix.stackexchange.com/questions/97261/…），所以我将尝试进一步挖掘，以后可能会有问题。谢谢！

— Mike B

作为专业的系统管理员，我们在乎这一点，但只限于一点-它在哪里以及如何影响操作。我认为我已经解决了这一方面。

— 迈克尔·汉普顿

@MikeB /proc/iomem将向您显示Linux有驱动程序的设备所使用的内存。e820内存映射（在dmesg刚启动的内核的最开始）将向您显示BIOS / EFI认为保留哪些区域。相互匹配是AFAIK的一项手动任务，不支持任何工具。

— mihi 2014年

该free命令的输出不计算保留的内核内存和其他一些小数。即使在64位内核中，甚至在<2GB RAM的情况下，您也会看到这种差异。

— 约翰
source

这不只是其他一些点...

— Michael Hampton

恩，不，不是字面上的8位字节中的位……但是，它最多只有几十MB。从百分比来看，它很小。

— 约翰

例如，在两个在VMware内部运行RHEL 5.10的64位系统中，一台2GB的“物理” RAM计算机总共显示2010 MB free，一台4GB的计算机显示3948 MB。

— 约翰

谢谢...奇怪的是，我在我的身上看到了如此大的差异，但这听起来可能是“正常的”。

— Mike B

不，这不是“正常”-800+ MB！

— 迈克尔·汉普顿

物理RAM映射中的关键行是：

 BIOS-e820: 0000000100000000 - 0000000140000000 (usable)

此行显示BIOS在4 GB以上的限制范围内已将1 GB（0x40000000字节，十六进制）的系统物理RAM映射，从而使32位没有PAE的系统无法访问它。

— 黄昏-无效-
source