Por que o comando "free" e o "dmidecode" mostram valores diferentes para a RAM?

Eu tenho um servidor CentOS 5.10 ( 32 bits ) em execução no VMWare. Está alocado 4 GB de RAM.

Se eu correr dmidecode -t 17 | grep Size | grep MB, vejo:

Size: 4096 MB

No entanto, quando corro free, vejo:

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

Por que há uma discrepância entre a quantidade total de freerelatórios de memória e a dmidecodesaída?

O kernel que estou executando é:

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

É certo que o kernel não está sendo executado, PAEmas eu pensei que isso era necessário apenas para memória superior a 4 GB.

Sei que estou perdendo algo simples - alguém pode, por favor, elaborar?

Notas / Observações adicionais

Definitivamente, parece que meu kernel está reservando um monte de memória para outras coisas. Aqui está o que eu vejo em /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

Respostas:

Com um kernel de 32 bits, você tem apenas 4 GB de espaço de endereço disponível . Parte desse espaço de endereço deve ser usado pelo hardware (virtual ou físico) do sistema, como placas de vídeo, placas de rede etc., para seus próprios propósitos. Esse uso geralmente varia entre 256 MB-1 GB, dependendo da quantidade de espaço de endereço que o hardware específico precisa.

Como esse espaço de endereço é usado pelo hardware, a RAM correspondente geralmente é inacessível a um sistema de 32 bits.

Você tem algumas opções:

A opção preferida é executar um sistema operacional de 64 bits. Isso expande drasticamente o espaço de endereço, para que haja bastante espaço para toda a RAM e hardware. Ele também quebra o limite de 2 GB / 3 GB de 32 bits em aplicativos, mantendo a capacidade de executar programas de 32 bits. Em geral, qualquer sistema com 2 GB ou mais de RAM deve executar um sistema operacional de 64 bits para evitar esses problemas.
Outra opção é executar um kernel de 32 bits com o PAE ativado. Isso exibirá a RAM, mas cada processo ainda será limitado a 2 GB / 3 GB de espaço de endereço, dependendo dos detalhes da compilação do kernel. Como os sistemas operacionais de 64 bits executam aplicativos de 32 bits perfeitamente, isso não tem vantagens e muitas desvantagens (como a falta de um caminho de atualização).

— Michael Hampton
fonte

Obrigado. Isso faz sentido, mas como posso verificar especificamente quanto é "oculto" / consumido pelo hardware para outros fins? Isso estaria abaixo /proc/meminfo?

— Mike B

@MikeB Especificamente, não tenho certeza de imediato, embora seja óbvio que algo em torno de 800 MB seja perdido.

— Michael Hampton

Para os fins da minha pergunta inicial, acho que foi respondida, mas a próxima pergunta é "POR QUÊ?". Parece que há outra discussão sobre isso ( unix.stackexchange.com/questions/97261/… ), então tentarei cavar um pouco mais e talvez tenha dúvidas mais tarde. Obrigado!

— Mike B

Como administradores de sistemas profissionais, nos preocupamos com isso, mas apenas até um ponto - onde e como isso afeta as operações. Eu acho que resolvi esse aspecto.

— Michael Hampton

O @MikeB /proc/iomemmostrará a memória usada pelos dispositivos para os quais o Linux possui um driver. O mapa de memória do e820 (no início de um dmesgkernel recém-inicializado) mostrará o que o BIOS / EFI pensa em quais regiões estão reservadas. Combiná-los um com o outro é AFAIK uma tarefa manual sem suporte de ferramenta.

— mihi

A saída do freecomando não conta a memória reservada do kernel e alguns outros pequenos bits. Você verá essa discrepância mesmo em um kernel de 64 bits e até com <2GB de RAM.

— John
fonte

Isso não é apenas a alguns outros pequenos pedaços ...

— Michael Hampton

Bem, não, literalmente não bits, como em 8 bits fazer um byte ... mas são apenas algumas dezenas de MB no máximo. Em porcentagem, é muito pequeno.

— John

Como exemplos, em dois sistemas de 64 bits executando o RHEL 5.10 no VMware, uma máquina RAM "física" de 2 GB mostra 2010 MB no total free, uma máquina de 4 GB mostra 3948 MB.

— John

Obrigado ... estranho que eu esteja vendo uma discrepância tão grande na minha, mas parece que isso pode ser "normal".

— Mike B

Não, isso não é "normal" - são mais de 800 MB!

— Michael Hampton

A linha crítica do seu mapa físico de RAM é esta:

 BIOS-e820: 0000000100000000 - 0000000140000000 (usable)

Essa linha mostra que 1 GB (0x40000000 bytes, hexadecimal) da RAM física do seu sistema está sendo mapeado pelo BIOS acima do limite de 4 GB, tornando-o inacessível por um sistema de 32 bits sem PAE.

— duskwuff -inactive-
fonte