У меня есть сервер Ubuntu с 320 ГБ памяти. Я установил xen 4.4.1 на эту машину и запустил две виртуальные машины Debian. Один с + -100 ГБ памяти и один с + -200 ГБ. Все работало нормально, пока в какой-то момент машина на 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
на виртуальной машине размером 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 ГБ.
Это означает, что что-то на уровне ядра / драйвера «украло» некоторую память для другого использования. Такой большой объем свободной памяти - идеальная цель для увеличения объема памяти. Вы можете найти больше информации здесь.