Почему команда «free» и «dmidecode» показывают разные значения для RAM?

У меня есть сервер 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 ГБ доступного адресного пространства . Часть этого адресного пространства должна использоваться (виртуальным или физическим) оборудованием в системе, таким как видеокарты, сетевые карты и т. Д., Для своих собственных целей. Такое использование обычно составляет от 256 МБ до 1 ГБ в зависимости от того, сколько адресного пространства требуется конкретному оборудованию.

Поскольку это адресное пространство используется аппаратными средствами, соответствующая оперативная память обычно недоступна для 32-разрядной системы.

У вас есть несколько вариантов:

Предпочтительным вариантом является запуск 64-битной операционной системы. Это значительно расширяет адресное пространство, поэтому в нем достаточно места для всей оперативной памяти и оборудования. Он также преодолевает 32-битный лимит в 2 ГБ / 3 ГБ для приложений, сохраняя возможность запуска 32-битных программ. Как правило, любая система с 2 ГБ ОЗУ должна работать под управлением 64-разрядной ОС, чтобы избежать этих проблем.
Другой вариант - запустить 32-битное ядро с включенным PAE. Это покажет оперативную память, но каждый процесс будет по-прежнему ограничен 2 ГБ / 3 ГБ адресного пространства, в зависимости от особенностей сборки ядра. Поскольку 64-разрядные ОС прекрасно работают с 32-разрядными приложениями, это не имеет никаких преимуществ и многих недостатков (таких как отсутствие пути обновления).

— Майкл Хэмптон
источник

Спасибо. Это имеет смысл, но как я могу конкретно проверить, сколько «скрыто» / потреблено оборудованием для других целей? Это будет под /proc/meminfo?

— Майк Б

@MikeB В частности, я не уверен в этом, хотя очевидно, что потеряно около 800 МБ.

— Майкл Хэмптон

Для целей моего первоначального вопроса, я думаю, что он ответил, но следующий вопрос «ПОЧЕМУ?». Похоже, что есть другая ветка, покрывающая это ( unix.stackexchange.com/questions/97261/… ), поэтому я попытаюсь покопаться еще и у меня могут появиться вопросы позже. Спасибо!

— Майк Б

Как профессиональные системные администраторы, мы заботимся об этом, но только до определенной степени - где и как это влияет на работу. Я думаю, что я обратился к этому аспекту.

— Майкл Хэмптон

@MikeB /proc/iomemпокажет вам память, используемую устройствами, для которых у Linux есть драйвер. Карта памяти e820 (в самом начале dmesgтолько что загруженного ядра) покажет вам, что ваш BIOS / EFI думает, какие регионы зарезервированы. Сопоставить их друг с другом - это AFAIK ручное задание без поддержки инструмента.

— Михи

Вывод freeкоманды не учитывает зарезервированную память ядра и несколько других маленьких битов. Вы увидите это несоответствие даже в 64-битном ядре и даже с <2 ГБ ОЗУ.

— Джон
источник

Это не просто несколько других маленьких кусочков ...

— Майкл Хэмптон

Ну, нет, не буквально биты, как в 8-битном-сделать-байте ... но это всего лишь несколько десятков МБ максимум. В процентном отношении это очень мало.

— Джон

Например, в двух 64-разрядных системах, работающих под управлением RHEL 5.10 внутри VMware, «физическая» память ОЗУ объемом 2 ГБ показывает общее количество 2010 МБ free, а машина объемом 4 ГБ - 3948 МБ.

— Джон

Спасибо ... странно, что я вижу такое большое расхождение в моем, но звучит так, как будто это может быть "нормально".

— Майк Б

Нет, это не «нормально» - это 800+ МБ!

— Майкл Хэмптон

Критическая строка из вашей физической карты памяти:

 BIOS-e820: 0000000100000000 - 0000000140000000 (usable)

Эта строка показывает, что 1 ГБ (0x40000000 байт, шестнадцатеричный) физического ОЗУ вашей системы отображается BIOS выше предела 4 ГБ, что делает его недоступным для 32-разрядной системы без PAE.

— сумеречный
источник