Pourquoi la commande «free» et «dmidecode» affichent des valeurs différentes pour la RAM?

J'ai un serveur CentOS 5.10 ( 32 bits ) fonctionnant sur VMWare. Il est alloué 4 Go de RAM.

Si je cours, dmidecode -t 17 | grep Size | grep MBje vois:

Size: 4096 MB

Pourtant, quand je cours free, je vois:

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

Pourquoi existe-t-il une différence entre la quantité totale de freerapports de mémoire et la dmidecodesortie?

Le noyau que j'utilise est:

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

Certes, le noyau ne fonctionne pas PAEmais je pensais que cela n'était nécessaire que pour une mémoire dépassant 4 Go.

Je sais qu'il me manque quelque chose de simple - quelqu'un peut-il élaborer?

Notes / observations supplémentaires

Il semble que mon noyau réserve un tas de mémoire pour d'autres choses. Voici ce que je vois dans /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
source

Réponses:

Avec un noyau 32 bits, vous n'avez que 4 Go d' espace d'adressage disponible . Une partie de cet espace d'adressage doit être utilisée par le matériel (virtuel ou physique) du système, comme les cartes vidéo, les cartes réseau, etc., à leurs propres fins. Cette utilisation se situe généralement entre 256 Mo et 1 Go en fonction de l'espace d'adressage dont le matériel particulier a besoin.

Étant donné que cet espace d'adressage est utilisé par le matériel, la RAM correspondante est généralement inaccessible à un système 32 bits.

Vous avez plusieurs options:

L'option préférée consiste à exécuter un système d'exploitation 64 bits. Cela augmente considérablement l'espace d'adressage, donc il y a beaucoup de place pour toute la RAM et le matériel. Il casse également la limite de 2 Go / 3 Go 32 bits sur les applications tout en conservant la possibilité d'exécuter des programmes 32 bits. En général, tout système avec 2 Go ou plus de RAM doit exécuter un système d'exploitation 64 bits pour éviter ces problèmes.
Une autre option consiste à exécuter un noyau 32 bits avec PAE activé. Cela affichera la RAM, mais chaque processus sera toujours limité à 2 Go / 3 Go d'espace d'adressage, selon les détails de la construction du noyau. Étant donné que les systèmes d'exploitation 64 bits exécuteront parfaitement les applications 32 bits, cela n'a aucun avantage et de nombreux inconvénients (comme l'absence de chemin de mise à niveau).

— Michael Hampton
source

Merci. Cela a du sens, mais comment puis-je vérifier spécifiquement la quantité «cachée» / consommée par le matériel à d'autres fins? Serait-ce sous /proc/meminfo?

— Mike B

@MikeB Plus précisément, je ne suis pas sûr au départ, bien qu'il soit évident que quelque part environ 800 Mo sont perdus.

— Michael Hampton

Aux fins de ma question initiale, je pense qu'il a été répondu, mais la question suivante est "POURQUOI?". Il semble qu'il y ait un autre thread couvrant cela ( unix.stackexchange.com/questions/97261/… ), je vais donc essayer de creuser un peu plus et je pourrais avoir des questions plus tard. Merci!

— Mike B

En tant qu'administrateurs système professionnels, nous nous soucions de cela, mais seulement jusqu'à un certain point - où et comment cela affecte les opérations. Je pense avoir abordé cet aspect.

— Michael Hampton

@MikeB /proc/iomemvous montrera la mémoire utilisée par les périphériques pour lesquels Linux a un pilote. La carte mémoire e820 (au tout début d'un dmesgnoyau fraîchement démarré) vous montrera ce que votre BIOS / EFI pense des régions réservées. Les comparer les uns aux autres est AFAIK une tâche manuelle sans support d'outils.

— mihi

La sortie de la freecommande ne compte pas la mémoire du noyau réservée et quelques autres petits bits. Vous verrez cette différence même dans un noyau 64 bits et même avec <2 Go de RAM.

— John
source

Ce n'est pas seulement quelques autres petits morceaux ...

— Michael Hampton

Eh bien, non, pas littéralement des bits comme dans 8 bits-make-a-byte ... mais ce n'est que quelques dizaines de Mo au plus. En pourcentage, c'est très petit.

— John

À titre d'exemple, dans deux systèmes 64 bits exécutant RHEL 5.10 dans VMware, une machine RAM "physique" de 2 Go affiche un total de 2010 Mo free, une machine de 4 Go affiche 3948 Mo.

— John

Merci ... étrange que je vois un si grand écart dans le mien, mais il semble que cela pourrait être "normal".

— Mike B

Non, ce n'est pas "normal" - c'est plus de 800 Mo!

— Michael Hampton

La ligne critique de votre carte RAM physique est la suivante:

 BIOS-e820: 0000000100000000 - 0000000140000000 (usable)

Cette ligne montre que 1 Go (0x40000000 octets, hexadécimal) de la RAM physique de votre système est mappé par le BIOS au-dessus de la limite de 4 Go, ce qui le rend inaccessible par un système 32 bits sans PAE.

— duskwuff -inactif-
source