「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
ソース

回答:

32ビットのカーネルでは、4 GBの利用可能なアドレス空間しかありません。このアドレス空間の一部は、ビデオカード、NICなど、システムの（仮想または物理）ハードウェアが独自の目的で使用する必要があります。この使用量は、特定のハードウェアが必要とするアドレススペースの量に応じて、通常256MB〜1GBです。

そのアドレス空間はハードウェアによって使用されるため、対応するRAMは一般に32ビットシステムにアクセスできません。

いくつかのオプションがあります。

64ビットオペレーティングシステムを実行することをお勧めします。これによりアドレススペースが大幅に拡張されるため、すべてのRAMとハードウェアに十分なスペースがあります。また、32ビットプログラムを実行する機能を維持しながら、アプリケーションの2GB / 3GB 32ビット制限を破ります。一般に、2 GB以上のRAMを搭載したシステムでは、これらの問題を回避するために64ビットOSを実行する必要があります。
別のオプションは、PAEを有効にして32ビットカーネルを実行することです。これによりRAMが再表示されますが、カーネルビルドの詳細に応じて、各プロセスは2GB / 3GBのアドレス空間に制限されます。64ビットOSは32ビットアプリケーションを完全に実行するため、これには利点がなく、多くの欠点があります（アップグレードパスがないなど）。

— マイケル・ハンプトン
ソース

ありがとう。それは理にかなっていますが、他の目的でハードウェアによって「隠されている」/消費されている量を具体的に確認するにはどうすればよいですか？それは下になり/proc/meminfoますか？

— マイクB

@MikeB具体的には、手元にあるかどうかはわかりませんが、800 MB前後が失われていることは明らかです。

— マイケルハンプトン

私の最初の質問では、答えはあると思いますが、次の質問は「なぜですか」です。これをカバーする別のスレッド（unix.stackexchange.com/questions/97261/…）があるようですので、さらに掘り下げてみますが、後で質問があるかもしれません。ありがとう！

— マイクB

私たちはプロのシステム管理者としてこれに関心を持っていますが、それができるのは、それが運用にどこでどのように影響するかということです。私はその側面に対処したと思います。

— マイケルハンプトン

@MikeB /proc/iomemは、Linuxがドライバーを持っているデバイスが使用しているメモリを表示します。e820のメモリマップ（dmesg新しくブートしたカーネルの最初の部分）は、BIOS / EFIがどの領域が予約されていると見なしているかを示します。それらを相互に一致させることは、ツールのサポートがなく手動タスクであるとAFAIKが考えています。

— mihi 2014年

freeコマンドの出力では、予約済みのカーネルメモリと他のいくつかの小さなビットはカウントされません。64ビットカーネルでも、<2GB RAMでも、この不一致が見られます。

— ジョン
ソース

それは他のいくつかの小さなことだけではありません...

— マイケルハンプトン

まあ、いや、8ビットのバイトを作るという文字通りのビットではありません...しかし、それはせいぜい数十MBです。パーセンテージでは、非常に小さいです。

— John

例として、VMware内でRHEL 5.10を実行している2つの64ビットシステムで、2GBの「物理」RAMマシンはで合計2010 MBを示しfree、4GBマシンは3948 MBを示します。

— John

ありがとう...奇妙なことに、私には大きな不一致が見られますが、それは「正常」であるように思えます。

— マイクB

いいえ、これは「正常」ではありません-800 MB以上です！

— マイケルハンプトン

物理RAMマップの重要な行は次のとおりです。

 BIOS-e820: 0000000100000000 - 0000000140000000 (usable)

この行は、システムの物理RAMの1 GB（0x40000000バイト、16進数）がBIOSによって4GBの制限を超えてマップされているため、PAEのない32ビットシステムからはアクセスできないことを示しています。

— duskwuff -inactive-
ソース