Eu tenho um servidor Ubuntu com 320 GB de memória. Eu instalei o xen 4.4.1 nesta máquina e executei 2 VMs do Debian. Um com + -100GB de memória e outro com + -200GB. Tudo funcionou bem, até que, em determinado momento, a máquina de 200GB informava ter apenas 128GB. O servidor tinha um tempo de atividade de 144 dias e, em algum momento, no último mês, mais de 70 GB de memória desapareceram.
no dom0:
$ sudo xl info
...
total_memory : 327634
free_memory : 16547
...
$ sudo xl list
Name ID Mem VCPUs State Time(s)
Domain-0 0 510 32 r----- 54.4
mycroft 1 102400 16 -b---- 33.3
adler 2 204000 16 -b---- 34.5
$ uname -a
Linux moriarty 3.13.0-32-generic #57-Ubuntu SMP Tue Jul 15 03:51:08 UTC 2014 x86_64 x86_64 x86_64 GNU/Linux
na VM com 204000MB de acordo com a lista xl:
$ free -m
total used free shared buffers cached
Mem: 128404 6220 122184 0 10 56
-/+ buffers/cache: 6152 122251
Swap: 0 0 0
$ uname -a
Linux adler 3.2.0-4-amd64 #1 SMP Debian 3.2.65-1+deb7u2 x86_64 GNU/Linux
$ cat /proc/meminfo
MemTotal: 131486352 kB
MemFree: 125117048 kB
Buffers: 11216 kB
Cached: 58016 kB
SwapCached: 0 kB
Active: 6057868 kB
Inactive: 47632 kB
Active(anon): 6036284 kB
Inactive(anon): 324 kB
Active(file): 21584 kB
Inactive(file): 47308 kB
Unevictable: 0 kB
Mlocked: 0 kB
SwapTotal: 0 kB
SwapFree: 0 kB
Dirty: 12 kB
Writeback: 0 kB
AnonPages: 6036296 kB
Mapped: 14740 kB
Shmem: 344 kB
Slab: 20024 kB
SReclaimable: 6504 kB
SUnreclaim: 13520 kB
KernelStack: 2728 kB
PageTables: 14824 kB
NFS_Unstable: 0 kB
Bounce: 0 kB
WritebackTmp: 0 kB
CommitLimit: 65743176 kB
Committed_AS: 91568356 kB
VmallocTotal: 34359738367 kB
VmallocUsed: 214612 kB
VmallocChunk: 34359523687 kB
HardwareCorrupted: 0 kB
AnonHugePages: 0 kB
HugePages_Total: 0
HugePages_Free: 0
HugePages_Rsvd: 0
HugePages_Surp: 0
Hugepagesize: 2048 kB
DirectMap4k: 208896000 kB
DirectMap2M: 0 kB
Eu já reiniciei ambos os servidores sem nenhum resultado: o dom0 continua reportando 204gB, a própria máquina reporta 128gB. Qual é a causa da diferença e como posso corrigir isso?
EDITAR
A saída do dmesg me dá isso
[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] Xen: 0000000000000000 - 00000000000a0000 (usable)
[ 0.000000] Xen: 00000000000a0000 - 0000000000100000 (reserved)
[ 0.000000] Xen: 0000000000100000 - 0000002000000000 (usable)
[ 0.000000] Xen: 0000002000000000 - 00000031ce000000 (unusable)
O alcance da última linha parece corresponder à falta de memória.
Eu tive o mesmo problema com o debian wheezy 7.8 convidados. A instalação do wheezy backports kernel 3.16.0-0.bpo.4-amd64 resolveu isso para mim. Isso foi nos convidados, eu não toquei no host.
Adicione a seguinte linha ao /etc/apt/sources.list:
deb http://ftp.uk.debian.org/debian/ wheezy-backports main
Em seguida, execute
apt-get update
apt-get -t wheezy-backports install linux-image-amd64
reboot
Você teve balões de memória no lugar? Em caso afirmativo, a memória "ausente" deve ser a memória recuperada pelo driver de balão.
Você pode postar a saída cat /proc/meminfo na máquina com a memória "ausente"?
EDITAR
Da sua saída / proc / meminfo, parece que o balão está funcionando de fato.
Dê uma olhada no valor "DirectMap4k": ele informa que cerca de 200 GB de RAM são gerenciados pela MMU com granularidade de 4k. Em outras palavras, o hardware virtualizado vê os 200 GB de RAM.
No entanto, o valor "MemTotal" mostra claramente que a memória total disponível é de "apenas" 135 GB.
Isso significa que algo no nível do kernel / driver "roubou" alguma memória para outro uso. Uma quantidade tão grande de memória livre é o alvo perfeito para o balão. Você pode encontrar mais informações aqui.