xen vm пропавшие без вести памяти
У меня есть сервер Ubuntu с 320 ГБ памяти. Я установил xen 4.4.1 на этой машине и выполнил 2 Debian VMs. Один с +-100GB памяти и один с +-200GB. Все хорошо работало, до однажды, отчеты о машине на 200 ГБ, имеющие только 128 ГБ. Сервер имел время работы 144 дней и где-нибудь в течение прошлого месяца, больше чем 70 ГБ памяти пропали.
на 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
на VM наличие 204000 МБ согласно списку 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
Я уже перезагрузил оба сервера без любого результата: dom0 продолжает сообщать о 204 ГБ, сама машина сообщает о 128 ГБ. Какова причина различия и как я могу зафиксировать его?
Править
Вывод dmesg дает мне это
[ 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)
Диапазон последней строки, кажется, соответствует недостающей памяти.
У меня была такая же проблема с гостями debian wheezy 7.8. Установка ядра wheezy backports 3.16.0-0.bpo.4-amd64 решила эту проблему за меня. Это было на гостях, я не трогал хост.
Добавьте следующую строку в /etc/apt/sources.list:
deb http://ftp.uk.debian.org/debian/ wheezy-backports main
Затем запустите
apt-get update
apt-get -t wheezy-backports install linux-image-amd64
reboot
Было ли у вас раздутие памяти? Если да, то «отсутствующей» памятью должна быть память, освобожденная драйвером балуна.
Можете ли вы опубликовать вывод cat / proc / meminfo на машине с «отсутствующей» памятью?
РЕДАКТИРОВАТЬ
Из вашего вывода / proc / meminfo кажется, что воздушный шар действительно работает.
Взгляните на значение "DirectMap4k": оно сообщает, что MMU управляет около 200 ГБ ОЗУ с детализацией 4k. Другими словами, виртуализированное оборудование видит все 200 ГБ ОЗУ.
Однако значение «MemTotal» ясно показывает, что общий доступный объем памяти составляет «всего» 135 ГБ.
Это означает, что что-то на уровне ядра / драйвера » украли "некоторую память для другого использования. Такой большой объем свободной памяти - идеальная цель для увеличения объема памяти. Дополнительную информацию можно найти здесь.