Perché il comando "free" e "dmidecode" mostrano valori diversi per la RAM?

Ho un server CentOS 5.10 ( 32 bit ) in esecuzione su VMWare. Sono allocati 4 GB di RAM.

Se corro dmidecode -t 17 | grep Size | grep MBvedo:

Size: 4096 MB

Eppure quando corro free, vedo:

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

Perché esiste una discrepanza tra la quantità totale di freerapporti di memoria e l' dmidecodeoutput?

Il kernel che sto eseguendo è:

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

Certo, il kernel non è in esecuzione PAEma ho pensato che fosse necessario solo per una memoria superiore a 4 GB.

So che mi manca qualcosa di semplice: qualcuno può per favore elaborare?

Note / osservazioni aggiuntive

Sembra proprio che il mio kernel stia riservando un sacco di memoria per altre cose. Ecco cosa vedo in /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
fonte

Risposte:

Con un kernel a 32 bit, hai solo 4 GB di spazio indirizzo disponibile . Parte di questo spazio di indirizzi deve essere utilizzato dall'hardware (virtuale o fisico) nel sistema, come schede video, schede di rete, ecc., Per i propri scopi. Questo utilizzo è in genere compreso tra 256 MB e 1 GB, a seconda della quantità di spazio di indirizzi richiesto dall'hardware specifico.

Poiché lo spazio degli indirizzi viene utilizzato dall'hardware, la RAM corrispondente è generalmente inaccessibile a un sistema a 32 bit.

Hai un paio di opzioni:

L'opzione preferita è eseguire un sistema operativo a 64 bit. Questo espande notevolmente lo spazio degli indirizzi, quindi c'è molto spazio per tutta la RAM e l'hardware. Inoltre, infrange il limite di 2 GB / 3 GB a 32 bit per le applicazioni mantenendo la capacità di eseguire programmi a 32 bit. In generale, qualsiasi sistema con 2 GB di RAM in più dovrebbe eseguire un sistema operativo a 64 bit per evitare questi problemi.
Un'altra opzione è eseguire un kernel a 32 bit con PAE abilitato. Questo svelerà la RAM, ma ogni processo sarà comunque limitato a 2 GB / 3 GB di spazio di indirizzi, a seconda dei dettagli della build del kernel. Poiché i sistemi operativi a 64 bit eseguiranno perfettamente le applicazioni a 32 bit, questo non ha alcun vantaggio e molti svantaggi (come la mancanza di un percorso di aggiornamento).

— Michael Hampton
fonte

Grazie. Ciò ha senso, ma come posso verificare in particolare quanto "nascosto" / consumato dall'hardware per altri scopi? Sarebbe sotto /proc/meminfo?

— Mike B,

@MikeB In particolare, non ne sono sicuro, anche se è ovvio che da qualche parte si perdono circa 800 MB.

— Michael Hampton,

Ai fini della mia domanda iniziale, penso che abbia una risposta, ma la domanda successiva è "PERCHÉ?". Sembra che ci sia un altro thread che copre questo ( unix.stackexchange.com/questions/97261/… ), quindi proverò a scavare un po 'di più e potrei avere domande in seguito. Grazie!

— Mike B,

In qualità di amministratori di sistema professionali, ci preoccupiamo di questo, ma solo fino a un certo punto: dove e come influisce sulle operazioni. Penso di aver affrontato questo aspetto.

— Michael Hampton,

@MikeB /proc/iomemti mostrerà la memoria utilizzata dai dispositivi per cui Linux ha un driver. La mappa di memoria e820 (all'inizio di un dmesgkernel appena avviato) ti mostrerà cosa pensa il tuo BIOS / EFI in quali regioni sono riservate. Abbinarli l'uno contro l'altro è AFAIK un'attività manuale senza supporto di strumenti.

— mihi,

L'output del freecomando non conta la memoria del kernel riservata e alcuni altri piccoli bit. Vedrai questa discrepanza anche in un kernel a 64 bit e anche con <2 GB di RAM.

— John
fonte

Non sono solo alcuni altri piccoli frammenti ...

— Michael Hampton,

Bene, no, non letteralmente bit come in 8-bit-make-a-byte ... ma sono solo poche decine di MB al massimo. Per quanto riguarda la percentuale, è molto piccolo.

— Giovanni,

Ad esempio, in due sistemi a 64 bit che eseguono RHEL 5.10 all'interno di VMware, una macchina RAM "fisica" da 2 GB mostra un totale di 2010 MB free, una macchina da 4 GB mostra 3948 MB.

— Giovanni,

Grazie ... strano che sto vedendo una discrepanza così grande nella mia, ma sembra che potrebbe essere "normale".

— Mike B,

No, questo non è "normale": sono oltre 800 MB!

— Michael Hampton,

La linea critica dalla tua mappa RAM fisica è questa:

 BIOS-e820: 0000000100000000 - 0000000140000000 (usable)

Questa riga mostra che 1 GB (0x40000000 byte, esadecimali) della RAM fisica del sistema viene mappato dal BIOS al di sopra del limite di 4 GB, rendendolo inaccessibile da un sistema a 32 bit senza PAE.

— duskwuff -inattivo-
fonte