Dlaczego polecenie „free” i „dmidecode” pokazują różne wartości pamięci RAM?

Mam serwer CentOS 5.10 ( 32-bitowy ) działający na VMWare. Przydzielono 4 GB pamięci RAM.

Jeśli uruchomię dmidecode -t 17 | grep Size | grep MB, zobaczę:

Size: 4096 MB

Jednak kiedy biegnę free, widzę:

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

Dlaczego istnieje rozbieżność między całkowitą ilością freeraportów pamięci a danymi dmidecodewyjściowymi?

Jądro, które uruchamiam to:

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

Wprawdzie jądro nie działa, PAEale pomyślałem, że jest to konieczne tylko w przypadku pamięci przekraczającej 4 GB.

Wiem, że brakuje mi czegoś prostego - czy ktoś mógłby wyjaśnić?

Dodatkowe uwagi / spostrzeżenia

Zdecydowanie wygląda na to, że moje jądro rezerwuje sporo pamięci na inne rzeczy. Oto co widzę w /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.
źródło

Odpowiedzi:

W przypadku jądra 32-bitowego masz tylko 4 GB dostępnej przestrzeni adresowej . Część tej przestrzeni adresowej musi być wykorzystywana przez (wirtualny lub fizyczny) sprzęt w systemie, taki jak karty graficzne, karty sieciowe itp., Do własnych celów. To użycie wynosi zwykle między 256 MB-1 GB, w zależności od tego, ile przestrzeni adresowej potrzebuje dany sprzęt.

Ponieważ ta przestrzeń adresowa jest używana przez sprzęt, odpowiednia pamięć RAM jest ogólnie niedostępna dla systemu 32-bitowego.

Masz kilka opcji:

Preferowaną opcją jest uruchomienie 64-bitowego systemu operacyjnego. To dramatycznie zwiększa przestrzeń adresową, więc jest dużo miejsca na całą pamięć RAM i sprzęt. Łamie również limit 32 GB na aplikacje 2 GB / 3 GB, zachowując jednocześnie możliwość uruchamiania programów 32-bitowych. Ogólnie rzecz biorąc, każdy system z 2 GB więcej pamięci RAM powinien mieć 64-bitowy system operacyjny, aby uniknąć tych problemów.
Inną opcją jest uruchomienie 32-bitowego jądra z włączonym PAE. Spowoduje to odsłonięcie pamięci RAM, ale każdy proces będzie nadal ograniczony do 2 GB / 3 GB przestrzeni adresowej, w zależności od szczegółów budowy jądra. Ponieważ 64-bitowe systemy operacyjne będą doskonale działać z 32-bitowymi aplikacjami, nie ma to żadnych zalet i wielu wad (takich jak brak ścieżki aktualizacji).

— Michael Hampton
źródło

Dzięki. Ma to sens, ale jak mogę dokładnie sprawdzić, ile jest „ukryte” / zużywane przez sprzęt do innych celów? Czy to byłoby poniżej /proc/meminfo?

— Mike B

@MikeB W szczególności nie jestem pewien, czy to od razu, choć oczywiste jest, że utracono około 800 MB.

— Michael Hampton

Na potrzeby mojego pierwszego pytania, wydaje mi się, że udzielono na nie odpowiedzi, ale następne pytanie brzmi „DLACZEGO?”. Wygląda na to, że jest w tym inny wątek ( unix.stackexchange.com/questions/97261/... ), więc spróbuję wykopać więcej i mogę mieć pytania później. Dzięki!

— Mike B

Jako profesjonalni administratorzy systemów dbamy o to, ale tylko do pewnego momentu - gdzie i jak wpływa to na operacje. Myślę, że zająłem się tym aspektem.

— Michael Hampton

@MikeB /proc/iomempokaże pamięć używaną przez urządzenia, dla których Linux ma sterownik. Mapa pamięci e820 (na samym początku dmesgświeżo uruchomionego jądra) pokaże ci, co myśli twój BIOS / EFI, które regiony są zarezerwowane. Dopasowywanie ich do siebie jest AFAIK ręcznym zadaniem bez wsparcia narzędziowego.

— mihi

Dane wyjściowe freepolecenia nie liczą zarezerwowanej pamięci jądra i kilku innych małych bitów. Zobaczysz tę rozbieżność nawet w 64-bitowym jądrze, a nawet z <2 GB pamięci RAM.

— Jan
źródło

To nie tylko kilka innych drobiazgów ...

— Michael Hampton

Cóż, nie, nie dosłownie bitów, jak w przypadku 8-bit-make-a-byte ... ale to tylko kilkadziesiąt MB. Pod względem procentowym jest bardzo mały.

— Jan

Jako przykład, w dwóch 64-bitowych systemach z RHEL 5.10 w VMware, „fizyczna” pamięć RAM o pojemności 2 GB pokazuje w sumie 2010 MB free, a maszyna o pojemności 4 GB - 3948 MB.

— John

Dzięki ... dziwne, że widzę tak dużą rozbieżność w mojej, ale wygląda na to, że to może być „normalne”.

— Mike B

Nie, to nie jest „normalne” - to ponad 800 MB!

— Michael Hampton

Linia krytyczna z twojej fizycznej mapy RAM jest następująca:

 BIOS-e820: 0000000100000000 - 0000000140000000 (usable)

Ta linia pokazuje, że 1 GB (0x40000000 bajtów, szesnastkowo) fizycznej pamięci RAM systemu jest mapowany przez BIOS powyżej limitu 4 GB, co czyni go niedostępnym dla systemu 32-bitowego bez PAE.

— Duskwuff -inactive-
źródło