Чому команда “вільний” та “dmidecode” показують різні значення для оперативної пам’яті?

У мене є сервер CentOS 5.10 ( 32-бітний ), який працює на VMWare. На це виділено 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-розрядним ядром у вас є лише 4 ГБ доступного адресного простору . Частина цього адресного простору повинна використовуватись у своїх цілях (віртуальні чи фізичні) апаратні засоби в системі, такі як відеокарти, NIC тощо. Зазвичай це використання становить від 256 МБ до 1 ГБ залежно від обсягу адресного простору.

Оскільки цей адресний простір використовується апаратним забезпеченням, відповідна ОЗУ, як правило, недоступна для 32-бітної системи.

У вас є пара варіантів:

1. Кращим варіантом є запуск 64-бітної операційної системи. Це різко розширює адресний простір, тому є достатньо місця для всієї оперативної пам’яті та обладнання. Він також порушує 32-бітний 32-розрядний ліміт додатків, зберігаючи можливість запускати 32-бітні програми. Загалом, будь-яка система з 2 ГБ більше оперативної пам’яті повинна мати 64-бітну ОС, щоб уникнути цих проблем.
2. Інший варіант - запустити 32-бітове ядро ​​з включеним PAE. Це дозволить приховати оперативну пам’ять, але кожен процес все одно буде обмежений 2 ГБ / 3 ГБ адресного простору, залежно від деталей побудови ядра. Оскільки 64-бітні ОС будуть добре запускати 32-розрядні програми, це не має переваг і багатьох недоліків (наприклад, відсутність шляху оновлення).

Вихід freeкоманди не враховує зарезервовану пам'ять ядра та кілька інших невеликих біт. Ви побачите цю невідповідність навіть у 64-бітному ядрі та навіть при <2 Гб оперативної пам’яті.

Критична лінія вашої фізичної карти ОЗУ:

 BIOS-e820: 0000000100000000 - 0000000140000000 (usable)

Цей рядок показує, що 1 Гб (0x40000000 байт, шістнадцятковий) фізичної оперативної пам’яті вашої системи відображається BIOS вище межі 4 ГБ, що робить її недоступною для 32-бітної системи без PAE.