+7 (495) 320-70-49
- Назад
- Телефоны
- +7 (495) 320-70-49
- Заказать звонок
info@proxmox.su
Москва, Бакунинская улица, 69с1
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Виртуальная машина Windows 10 и Ballooning -> почти 100% использования оперативной памяти., Proxmox Виртуальная Среда

rumble06

Guest

14.07.2019 14:17:00

После включения ballooning и следования вики (установил драйвера и запустил ballooningservice в Windows), вместо снижения использования ОЗУ в панели Proxmox, использование ОЗУ в VM наоборот увеличилось. Минимальный объем ОЗУ: 2048MB, общий объем ОЗУ, выделенный VM: 14336MB. Однако использование достигло 90% как в панели Proxmox, так и в Task Manager в VM.

Редактировал: Удаление или остановка ballooningservice не помогли, использование ОЗУ по-прежнему было выше 90% постоянно (даже сразу после загрузки), что составляло более 12GB из 14GB, выделенных VM.

Но, после нажатия "Удалить устройство" на Virtio Ballooning в диспетчере устройств проблема была решена, текущее использование ОЗУ в VM составляет всего 2.5GB (хотя Proxmox этого не отображает, поэтому я и хочу использовать ballooning service).

Редактировал 2: Похоже, в драйвере ballooning для Windows есть утечка памяти. После повторной установки драйвера я проверил Task Manager, использование ОЗУ увеличивается на +100MB каждые 3-4 секунды и не прекращается.

elagil

Guest

09.01.2020 08:42:00

Когда обе машины работают с более консервативными настройками памяти (VM1: 1-8 ГБ ОЗУ, VM2: 1-6 ГБ ОЗУ, так что перераспределение отсутствует), вот что я получаю из "free -h" после некоторого простоя в 5 минут и с включённым ballooning:

Bash: root@pc:~# free -h
total used free shared buff/cache available
Mem: 15Gi 14Gi 208Mi 17Mi 461Mi 316Mi
Swap: 8.0Gi 545Mi 7.5Gi

Похоже, что для хоста практически не осталось доступной памяти. Я также не понимаю, почему хост падает в случае перераспределения, даже если ОЗУ недоступна. Для этого всё ещё достаточно места на свопе.

Прилагаю статистику двух ВМ (vm1.png/vm2.png). Обе работают с включённым ballooning, и отображение ОЗУ точное. Процесс "BLNSRV.exe" присутствует в диспетчере задач на обеих, и драйвер ballooning также виден в диспетчере устройств и работает нормально.

Прилагаю системный журнал при работе этих двух ВМ. Заметил, что ВМ Windows становятся медленнее в отклиде, когда ОЗУ заполнена настолько, как это происходит при этих настройках (см. ram.png).

Для полноты, вот конфигурационные настройки:

VM1: Bash: root@pc:~# qm config 101
agent: 1
balloon: 1024
bios: ovmf
boot: cdn
bootdisk: scsi0
cores: 8
cpu: host
efidisk0: local-lvm:vm-101-disk-1,size=128K
hostpci0: 0a:00,x-vga=1,pcie=1,romfile=GTX1070.bin
hostpci1: 0b:00.3,pcie=1
machine: q35
memory: 8192
name: Windows10a
net0: virtio=F6:FB:DE:3A:E5:8B,bridge=vmbr0,firewall=1
numa: 1
onboot: 1
ostype: win10
scsi0: local-lvm:vm-101-disk-0,backup=0,cache=writeback,iothread=1,size=128G,ssd=1
scsihw: virtio-scsi-single
smbios1: uuid=272870d3-f14e-4ae2-b9b9-a47e1b6ecd4b
sockets: 1
vga: none
vmgenid: b5558763-7896-4b51-bff3-ad1cc7627879

VM2 Bash: root@pc:~# qm config 110
agent: 1
balloon: 1024
bios: ovmf
bootdisk: scsi0
cores: 8
cpu: host
efidisk0: local-lvm:vm-102-disk-1,size=128K
hostpci0: 01:00,pcie=1,x-vga=1
machine: q35
memory: 6144
name: Windows10b
net0: virtio=CE:21:FB:FA:E2:41,bridge=vmbr0,firewall=1
numa: 1
ostype: win10
scsi0: local-lvm:vm-102-disk-0,backup=0,cache=writeback,iothread=1,size=128G,ssd=1
scsihw: virtio-scsi-single
smbios1: uuid=b8d50aee-0211-4e45-ae22-b284360bbf0c
sockets: 1
usb0: host=0416:0123
usb1: host=feed:2260,usb3=1
usb2: host=1532:0016
vga: none
vmgenid: 3b7dd095-86d4-4712-9ea6-4f18ee215381

У вас есть какие-нибудь идеи, с чего начать поиск неисправности?

tim Guest	#3 0 09.01.2020 10:54:00 Это не системный журнал аварийного сбоя, это просто фрагмент логов, когда ты запустил обе виртуальные машины. Что потребляет память в твоей виртуальной машине?

elagil

Guest

09.01.2020 11:06:00

Да, это не после вылета, я запишу еще один, когда вечером произойдет сбой. В списке задач нет процессов, которые много памяти потребляют вообще. Я не вижу источник расхода памяти. Blnsrv.exe тоже использует очень мало, около 1 МБ. Я еще выложу скриншот списка процессов, когда будет возможность. Есть ли скрытые процессы, которые диспетчер задач по умолчанию не отображает? Редактирую: посмотрю на монитор ресурсов.

tim

Guest

09.01.2020 11:21:00

Я, честно говоря, не знаю, так ли это с Windows, но, возможно, некоторые процессы скрыты или не соответствуют протоколу диспетчера задач или что-то в этом роде. Разве файлы syslog после последнего сбоя еще доступны?

elagil

Guest

09.01.2020 13:09:00

Да, попробую посмотреть диспетчер ресурсов, там должно быть видно и системные процессы, которые я не вижу в диспетчере задач. Может быть, но не знаю, какой именно из них виноват в ротации логов. Ну, да ладно, пусть лучше снова вылетит.

elagil

Guest

09.01.2020 18:45:00

Прилагаю выхлоп syslog с дампом. Там одна ВМ была перезагружена с "небезопасными" настройками, то есть минимальный объем ОЗУ 1 ГБ и максимальный 12 ГБ, а на другом сервере 2 ГБ минимально и 6 ГБ максимально. Перезагрузка происходит вот здесь: Код: Jan 9 18:35:52 pc qmeventd[874]: Restarting VM 101. В общем, я там ничего полезного не вижу. После 18:36:00 логи продолжаются после перезагрузки. В resmon/poolmon вообще не видно чрезмерного использования ОЗУ процессами или драйверами.

tim Guest	#8 0 10.01.2020 11:25:00 Это снова лишь малая часть системного журнала, без какой-либо информации о сбое.

elagil Guest	#9 0 10.01.2020 11:36:00 Я понимаю твою обеспокоенность, но это все, что у меня есть в syslog. Во время сбоя ничего не добавляется. Я получил это с помощью "cat /var/log/syslog" после перезагрузки.

tim Guest	#10 0 10.01.2020 12:06:00 Просто чтобы уточнить, мы всё ещё говорим о том, что Proxmox хост падает? Как мне кажется, там была команда "tail", а не "cat", и я сомневаюсь, что в твоём системном журнале больше 55 строк, начиная с 6 вечера.

elagil

Guest

#11

10.01.2020 12:52:00

Поведение системы такое: я перезагружаю проблемную VM с настройками памяти, приводящими к перерасходу, всё зависает (VM, веб-интерфейс, SSH становится неотзываемым), и хост Proxmox тоже перезагружается. Я извлек syslog после принудительной перезагрузки, который, конечно, получился очень длинный. Вы правы, я использовал `tail`, и это не полный syslog. Извините за путаницу. Тем не менее, я выложил часть, которая включает всё между этими двумя событиями: Код: Jan 9 18:35:46 pc pvedaemon[6712]: запрошена перезагрузка VM 101: UPID:pc:00001A38:00021DA5:5E176472:qmreboot:101:root@pam: Здесь VM 101 была перезапущена с измененными настройками, так что RAM перерасходована. Логи продолжаются до Код: Jan 9 18:36:00 pc systemd[1]: Запуск Proxmox VE репликационного движка... – это последняя строка, которую содержит syslog, перед тем как система перезагружается из-за сбоя. Следующая строка появилась через несколько минут и содержит сообщения о запуске Proxmox. Мне кажется, я должна была включить эти строки, чтобы избежать недопонимания, поэтому прошу извинить. В данный момент у меня нет доступа к машине, поэтому я не могу прикрепить остальное. Как я уже упоминала, во время фактического сбоя в syslog не добавляются строки, система просто останавливается.

Vaielab

Guest

#12

10.01.2020 16:42:00

Привет! Кажется, у меня та же проблема. Вижу, что, как и я, ты используешь GPU passthrough в своей VM, пытаясь при этом настроить memory ballooning. Если запустить только одну VM с ballooning (с безопасным количеством памяти) и сравнить использование памяти изнутри VM и из Proxmox, память вообще уменьшается или всегда остается на максимальном значении ballooning? И можешь ли ты повторить этот же тест, но без GPU passthrough, чтобы проверить, будет ли это работать?

tim Guest	#13 0 17.01.2020 10:35:00 В общем, qemu нужно выделить весь объем памяти сразу, если ты используешь проброс видеокарты, из-за требования к отображению памяти, которое необходимо для этого.

tim Guest	#14 0 05.09.2019 12:31:00 Какую версию драйверов virtio вы используете?

elagil

Guest

#15

04.01.2020 22:06:00

У меня та же проблема в Windows 10 1909, только что установил. Пробовал последнюю версию (1.173), а также стабильную (1.171) и убедился, что служба ballooning работает и драйвера установлены. Но все равно при работе службы ballooning увеличивается использование оперативной памяти. Другую проблему я столкнулся на двух компьютерах с Windows 10, где была включена служба ballooning: Proxmox полностью зависал и перезагружался со следующими настройками и при запуске обеих виртуальных машин: VM1: 2 ГБ мин. ОЗУ, 8 ГБ макс. ОЗУ VM2: 4 ГБ мин. ОЗУ, 16 ГБ макс. ОЗУ У меня 16 ГБ системной памяти и другие виртуальные машины не запущены, поэтому я ожидал, что это будет работать. Ballooning был включен для обеих, и служба ballooning работала (драйвера тоже установлены). Использование ОЗУ правильно отображалось для обеих машин в веб-интерфейсе Proxmox, когда они запускались по отдельности.

tim

Guest

#16

07.01.2020 10:54:00

Что в твоем системном журнале? Я бы предположил, что у хоста закончилась память, и поэтому он упал. Если у тебя всего 16 ГБ памяти, а одна из твоих ВМ может занять всё это, то не удивительно, что хост испытывает трудности.

elagil

Guest

#17

07.01.2020 12:44:00

Машины в режиме простоя занимают около 3 ГБ оперативной памяти, так что с гостевой стороны использование памяти не было чрезмерным. Я так понимаю, ballooning должен управлять оперативной памятью, значит, можно её перераспределять? Если ballooning включен в веб-GUI Proxmox, то кажется, что есть утечка памяти, и каждые 3-4 секунды использование памяти в Windows увеличивается на 100 МБ. Я выяснил, что даже после отключения службы ballooning это поведение сохраняется, поэтому предполагаю, что причина утечки памяти — драйвер ballooning. Отключение ballooning в GUI тоже прекращает утечки памяти. Позже проверю syslog.

tim

Guest

#18

07.01.2020 13:08:00

Ну да, но вы же сами говорили, что ballooning внутри вашей VM не работает, что уж там по какой-то причине, так что, скорее всего, работает как не положено. Без логов и статистики с того времени сложно что-то сказать.

elagil Guest	#19 0 07.01.2020 15:33:00 Окей, скоро вернусь с дополнительной информацией. Не могли бы вы подсказать, какие логи стоит посмотреть, кроме syslog?

elagil Guest	#20 0 08.01.2020 09:36:00 Конфигурация тестирования была следующей: у VM1/VM2 минимум 2 ГБ ОЗУ и максимум 8 ГБ ОЗУ с включенным ballooning. Отображение использования ОЗУ в интерфейсе пользователя Proxmox работает корректно, то есть отображение использования ОЗУ Windows и Proxmox согласовано. Использование ОЗУ медленно снижается с 90% с течением времени, пока не достигнет нормального уровня. Однако, когда одна машина работает (простаивает с примерно 3 ГБ использованной ОЗУ), запуск второй машины все равно полностью приводит к сбою Proxmox. В системном журнале нет никаких дополнительных записей, когда происходит сбой, если смотреть его с помощью "tail -f /var/log/syslog" по ssh, а также в оболочке в веб-интерфейсе на клиентской VM. С включенным и выключенным ballooning, содержимое системного журнала при запуске VM одинаково. К сожалению, я не успел его зафиксировать и сделаю это позже.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры