¿Por qué el comando "libre" y "dmidecode" muestran diferentes valores para RAM?

Tengo un servidor CentOS 5.10 ( 32 bits ) ejecutándose en VMWare. Se le asignan 4 GB de RAM.

Si corro dmidecode -t 17 | grep Size | grep MBveo:

Size: 4096 MB

Sin embargo, cuando corro free, veo:

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

¿Por qué hay una discrepancia entre la cantidad total de freeinformes de memoria y la dmidecodesalida?

El núcleo que estoy ejecutando es:

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

Es cierto que el kernel no se está ejecutando, PAEpero pensé que solo era necesario para una memoria superior a 4 GB.

Sé que me falta algo simple. ¿Alguien puede dar más detalles?

Notas / observaciones adicionales

Definitivamente parece que mi kernel está reservando un montón de memoria para otras cosas. Esto es lo que veo en /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
fuente

Respuestas:

Con un kernel de 32 bits, solo tiene 4 GB de espacio de direcciones disponible . Parte del espacio de direcciones debe ser utilizado por el hardware (virtual o físico) del sistema, como tarjetas de video, NIC, etc., para sus propios fines. Este uso suele estar entre 256 MB y 1 GB, dependiendo de cuánto espacio de direcciones necesite el hardware en particular.

Dado que el hardware usa ese espacio de direcciones, la RAM correspondiente generalmente es inaccesible para un sistema de 32 bits.

Tienes unas cuantas opciones:

La opción preferida es ejecutar un sistema operativo de 64 bits. Esto expande drásticamente el espacio de direcciones, por lo que hay mucho espacio para toda la RAM y el hardware. También rompe el límite de 2 GB / 3GB de 32 bits en las aplicaciones al tiempo que mantiene la capacidad de ejecutar programas de 32 bits. En general, cualquier sistema con 2 GB de RAM más debe ejecutar un sistema operativo de 64 bits para evitar estos problemas.
Otra opción es ejecutar un kernel de 32 bits con PAE habilitado. Esto mostrará la RAM, pero cada proceso estará limitado a 2GB / 3GB de espacio de direcciones, dependiendo de los detalles de la construcción del núcleo. Dado que los sistemas operativos de 64 bits ejecutarán aplicaciones de 32 bits perfectamente bien, esto no tiene ventajas y muchas desventajas (como la falta de una ruta de actualización).

— Michael Hampton
fuente

Gracias. Eso tiene sentido, pero ¿cómo puedo verificar específicamente cuánto está "oculto" / consumido por el hardware para otros fines? ¿Eso estaría debajo /proc/meminfo?

— Mike B

@MikeB Específicamente, no estoy seguro de antemano, aunque es obvio que se pierden alrededor de 800 MB.

— Michael Hampton

Para el propósito de mi pregunta inicial, creo que está respondida, pero la siguiente pregunta es "¿POR QUÉ?". Parece que hay otro hilo que cubre esto ( unix.stackexchange.com/questions/97261/… ), así que intentaré cavar un poco más y quizás tenga preguntas más adelante. ¡Gracias!

— Mike B

Como administradores de sistemas profesionales, nos preocupamos por esto, pero solo hasta cierto punto: dónde y cómo afecta las operaciones. Creo que he abordado ese aspecto.

— Michael Hampton

@MikeB /proc/iomemle mostrará la memoria utilizada por los dispositivos para los que Linux tiene un controlador. El mapa de memoria e820 (al comienzo de un dmesgnúcleo recién arrancado) le mostrará lo que su BIOS / EFI piensa qué regiones están reservadas. Hacerlos coincidir entre sí es AFAIK, una tarea manual sin soporte de herramientas.

— mihi

La salida del freecomando no cuenta la memoria del núcleo reservada y algunos otros pequeños bits. Verá esta discrepancia incluso en un kernel de 64 bits e incluso con <2 GB de RAM.

— Juan
fuente

Eso no es solo algunas otras pequeñas cosas ...

— Michael Hampton

Bueno, no, no literalmente bits como en 8-bit-make-a-byte ... pero solo son unas pocas decenas de MB como máximo. En cuanto al porcentaje, es muy pequeño.

— John

Como ejemplos, en dos sistemas de 64 bits que ejecutan RHEL 5.10 dentro de VMware, una máquina RAM "física" de 2 GB muestra un total de 2010 MB free, una máquina de 4 GB muestra 3948 MB.

— John

Gracias ... extraño que estoy viendo una gran discrepancia en la mía, pero parece que eso podría ser "normal".

— Mike B

No, esto no es "normal": ¡son más de 800 MB!

— Michael Hampton

La línea crítica de su mapa de RAM física es esta:

 BIOS-e820: 0000000100000000 - 0000000140000000 (usable)

Esta línea muestra que 1 GB (0x40000000 bytes, hexadecimal) de la RAM física de su sistema está siendo mapeado por el BIOS por encima del límite de 4 GB, por lo que es inaccesible para un sistema de 32 bits sin PAE.

— duskwuff -inactive-
fuente