qemu не правильно отображает потребление ОЗУ VM

Что за «график qemu»? И с какой колонкой в htop ты сравниваешь?

https://virt-manager.org/ Позволяет удобно использовать qemu-kvm. В этой программе есть график потребление ресурсов виртуальной машины,она потребление ОЗУ не правильно показывает(завышает показатель)нагрузку на одно ядро/один поток(CPU) правильно показывает а вот потребление ОЗУ завышает.

Так бы и написал что virt-manager отображает. Так и с какой колонкой в htop ты сравнивал? Там есть VIRT, RES, SHR, и кстати ни одна из них не может считаться точной оценкой потребления памяти.

htop уже в виртуалке был,он не может врать т.к.проверен временем. https://yandex.ru/images/touch/search?text=linux%20htop&source=tabbar&pos=1&img_url=https%3A%2F%2Fzenway.ru%2Fuploads%2Flinuxsoft%2Fhtop_003.png&rpt=simage

А, так это вообще не то. Это количество памяти, которое ОС виртуалки считает занятым под что-то полезное. Сравни: количество памяти, которое qemu выделил для ОС виртуалки. Очевидно, второе не может быть меньше первого, а вот больше - запросто. Особенно с учётом того, что qemu не может достоверно определить, какая именно память виртуалки занята полезным, а какая - мусором (ОС изнутри виртуалки не имеет способов ему об этом сообщить).

Итого, если тебе нужно узнать сколько памяти потрачено на работу виртуалки - то число из virt-manager-а скорее всего ближе к истине. Но прям точно нигде не будет написано, это общее свойство любых измерений памяти в современных ОС.

Ну похоже да на работу виртулки а не сколько конкретно внутри виртулки потреблено. Например 1гб под процессы qemu-kvm,остальные выделенные 8гб в виртуалку но тогда зачем она делает расчет этот в графике для виртуалки,она же врет получается,т.к виртуалке выделенные 8гб,виртулка потребляет 200мб а график пишет что 500мб,когда htop внутри виртулки пишет что 200. VMware workstation pro имеет 2гб ОЗУ мин требований,неужели qemu-kvm тяжёлая тоже? Мб утечка ОЗУ у qemu-kvm? Мб баганная.

Ты не совсем понял меня,я про то что htop всегда честно измеряет раз им пользуются,htop это как диспетчер задач только для Linux server.

Нет не врёт. Там указано сколько памяти тратится на виртуалку. Повторяю, «виртуалка потратила память компа» (500) и «программа внутри виртуалки потратила память виртуалки» (200) это совершенно разные вещи. И второе снаружи вообще не видно никак.

И делай меньше опечаток плз.

Потратила 200мб озу из 8000мб ОЗУ. Ну почему может жрать столько ОЗУ виртуалка? Поедание Доходило до 2000Мб ОЗУ когда внутри виртуалки больше ОЗУ использовано было.

Где логика у тебя? Зачем виртуалки нужно 2гига? То что внутри нее потребит 8гигов но зачем программе столько ОЗУ? Это же всего лишь навсего виртуализация а ресурсы расходуются как на полноценный мини сервер.

Перестань бредить. Если ты считаешь что сам всё знаешь то не надо было создавать тему с вопросом. Если же не знаешь то читай что тебе отвечают и пытайся понять, пока что это у тебя не получается судя по всему.

Ещё раз: 500МБ это то, сколько памяти взяла себе виртуалка. Часть из них оказалась занята полезными данными (200МБ). Остальные 300МБ, видимо, заняты мусором. Но о том, что это мусор, знает только ОС внутри виртуалки (и показывает в htop). qemu же этого не знает, он видит что виртуалка забрала 500МБ и это число и показывает. Вот это - попытайся понять, а не спорить и возражать.

Причина этого всего в том, что на обычных компьютерах понятия «потраченной с целом памяти» вообще не существует. Если у тебя есть комп с 8ГБ памяти, то у ОС на нём всегда будут эти 8ГБ, она не может от половины из них отказаться и кому-то отдать. У виртуалок же, из 8ГБ памяти виртуалки, есть резон не отдавать ей их все сразу, а отдавать только тогда, когда она захочет что-то с ними сделать. Виртуалка потрогала 500МБ, ей их дали. Но пользуется сейчас - только 200МБ из них.

Выделенная память виртуальной машине + используемая память процесса qemu и вспомогательных оберток.

Виртуалка может занимать память разными способами:

• Под работающие приложения - htop это показывает зеленым и включает в свою цифру справа. Очевидно, qemu должен хранить содержимое этой памяти, и virt-manager считает ее потребленной.
• Под дисковый кеш - htop это показывает желтым и НЕ включает в свою цифру справа. Но поскольку эту память терять нельзя (виртуалка к ней может обратиться в любой момент), qemu тоже должен хранить содержимое этой памяти, и virt-manager считает ее потребленной.
• Под всякие мелочи типа буферов.
• Под старье. Т.е. раньше эта память использовалась (приложением или под дисковый кеш), сейчас стала не нужна, и ядро считает ее свободной. htop показывает это черным. Но ядро эту память не чистит (так как это дорого по времени и на реальном железе не нужно), там остаются не нули, и qemu не знает и знать пока не может, что это на самом деле мусор. И честно его хранит и потребляет память хоста под хранение этого мусора. Мало ли, вдруг пользователь на самом деле в виртуалке тестирует работоспособность какого-нибудь эксплойта, который обращается (намеренно) к освобожденной памяти - так что даже мусор хранить, к сожалению, нужно.

Чтобы такого не было, придумали «virtio-balloon free page hinting», и это работает, начиная с linux-5.7.x и qemu-5.1.x. Но по умолчанию все равно выключено, и в virt-manager’е это не включить никак, только при запуске qemu руками.

Поправка: в libvirt v6.9.0 (2020-11-02) поддержка free-page-reporting есть, можно включить через правку XML-описания виртуалки.

А не подскажешь где надо править XML? Что туда вбивать и в какую строку?

Мусор только в Java вот только Java приложении не запущено раз ОЗУ 200мб съедает из коробки. У Java есть GC который чистит мусор. Ты не разбираешься как работает виртуализация kvm/openVZ а лезешь куда-то,сначало испробуй основные проги:qemu-kvm/virtual box мб тогда будешь понимать процессы.

Править XML можно в новых версиях virt-manager’а. Edit > Preferences, ставишь галку «Enable XML Editing». Создаешь виртуалку как обычно, потом переходишь на вкладку с оборудованем, а там на XML. Ищешь memballoon, он до внесения правок обычно выглядит так:

    <memballoon model="virtio">
      <address type="pci" domain="0x0000" bus="0x05" slot="0x00" function="0x0"/>
    </memballoon>

Или редактируешь через virsh -c qemu:///system edit your-vm-name.

Файл в итоге попадает в /etc/libvirt/qemu/your-vm-name.xml, но его напрямую как файл редактировать нельзя - не применится и перетрется.

Надо добавить атрибуты, документированные в https://libvirt.org/formatdomain.html#memory-balloon-device. Они все необязательные и могут быть добавлены независимо. Нас интересует freePageReporting, но и другие тоже можно добавить. Например, может получиться такое:

    <memballoon model="virtio" autodeflate="on" freePageReporting="on">
      <stats period="1"/>
      <address type="pci" domain="0x0000" bus="0x05" slot="0x00" function="0x0"/>
    </memballoon>

И потом можно смотреть статистику через virsh:

$ virsh -c qemu:///system
...
virsh # dommemstat archlinux --period 1 --live    # если элемент stats не добавлен в XML

virsh # dommemstat archlinux
actual 1048576
swap_in 0
swap_out 0
major_fault 605
minor_fault 1081699
unused 126968
available 972252
usable 687412
last_update 1654362578
disk_caches 644436
hugetlb_pgalloc 0
hugetlb_pgfail 0
rss 1089508

В виртуалке можно потестировать выделение и освобождение памяти и посмтореть, как это отображается в dommemstat:

$ python3
Python 3.10.4 (main, May 14 2022, 05:21:19) [GCC 12.1.0] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> hog = "a" * 1024 * 1024 * 512
>>> del hog
>>> 

Ошибка изменения конфигурации виртуальной машины: (domain_definition):181: Opening and ending tag mismatch: memballoon line 173 and rng ———-^

Traceback (most recent call last): File «/usr/share/virt-manager/virtManager/addhardware.py», line 344, in change_config_helper define_func(**define_args) File «/usr/share/virt-manager/virtManager/details/details.py», line 1372, in change_cb return self.vm.define_xml(newxml) File «/usr/share/virt-manager/virtManager/object/libvirtobject.py», line 347, in define_xml self._redefine_xml_internal(origxml, newxml) File «/usr/share/virt-manager/virtManager/object/libvirtobject.py», line 374, in _redefine_xml_internal self._define(newxml) File «/usr/share/virt-manager/virtManager/object/domain.py», line 1119, in _define self.conn.define_domain(xml) File «/usr/share/virt-manager/virtManager/connection.py», line 554, in define_domain return self._backend.defineXML(xml) File «/usr/lib/python3/dist-packages/libvirt.py», line 4414, in defineXML raise libvirtError(‘virDomainDefineXML() failed’) libvirt.libvirtError: (domain_definition):181: Opening and ending tag mismatch: memballoon line 173 and rng ———-^ вот что пишет при поптыке добавить:

удалось таки вбить код который скинул,но показывает в графике 1124MB а в htop 565MB - куда еще 500МБ уходит?

Объясняю еще раз.

Htop показывает цифрой, сколько памяти занято приложениями. Эту же цифру он показывает в виде зеленой полоски. Еще он показывает желтую полоску - это дисковый кеш. Еще теоретически бывает мусор, но моя XML-ка его убирает.

Htop показывает цифрой память, занятую приложениями, но не дисковым кешем, не буферами, и не мусором. Он так может делать, поскольку запущен в гостевой системе и может об этом спросить ядро.

QEMU (и, следовательно, libvirt) понятия не имеет и не может иметь (и, как эмулятор процессора, а не операционки, не должен иметь), что такое приложения, что такое дисковый кеш, что такое буфер, и что является мусором. Соответственно, показывает сумму этих значений.

Предлагаю для понимания еще такой эксперимент провести. В одном терминале в свежезагруженной виртуалке запустить htop, а в другом вот это:

cat /usr/bin/* > /dev/null

Т.е. прочитать все программы и ничего не делать с результатом.

Смотри - цифра в htop не выросла, зеленая полоска не выросла, а желтая выросла, поскольку ядро поместило содержимое этих файлов в кеш, чтобы второй раз с диска не читать. То же самое можно посмотреть командой free -m, или так: cat /proc/meminfo. И free, и top, и htop берут информацию об общем потреблении памяти из /proc/meminfo, и ниоткуда больше. И смотри - потребление памяти по версии libvirt выросло на столько же, на сколько вырос дисковый кеш (Cached: ... в /proc/meminfo).

Теперь предлагаю сбросить кеш:

echo 3 | sudo tee /proc/sys/vm/drop_caches

…и посмотреть, что изменилось.

Какой кэш какой мусор на Ubuntu server 22.04? Ты не путай Minecraft server где мусорщик есть т.к он на джава. Линукс работает с памятью как винда, сколько нужно столько потребит приложение,выключил его потребление снизилось и т.д. Если кэш как ОЗУ на жёстком диске то сервер залагает. Так что не знаю откуда ты выдумал это все. Просто раз он не знает по твоим словам а значит глючит. Ну что же думаю лучше другую Вирт программу найти,мне главное хорошая производительность на CPU а то в инете пишут что разница между ними есть но вот какая хз.

А я и не путаю, смотри первоисточник (в данном случае - /proc/meminfo и man 5 proc). Linux использует ОЗУ не только для приложений, но и как дисковый кеш, чтобы не читать два раза одно и то же и чтобы не читать то, что сам же и записал. В google по фразе «linux ate my ram» есть много хороших объяснений. Еще можно почитать про Page Cache, это он и есть.

Собственно, весь тред про то, что htop показывает циферками только память, занятую приложениями, т.е. ту, которую ядро при всем желании освободить не сможет, кроме как путем выгрузки в swap. Page Cache в эти циферки не входит, хотя тоже находится в памяти, рядом с приложениями. Память, занятая Page Cache, не является свободной: если там будет сбойный бит, есть риск получить неверные данные при повторном чтении «с диска» того, что на самом деле закешировано. Но память, занятая Page Cache, может быть быстро освобождена под другие цели, когда понадобится, и поэтому с точки зрения пользователя практически равноценна свободной. Тогда как с точки зрения системы виртуализации, память, которую хоть раз трогали с любой целью и после этого не пометили, как свободную, через balloon, является занятой.

Касательно мусора, согласен, обычно об этом не пишут, поскольку в контексте, отличном от виртуализации, это просто свободная память, которую операционная система не почистила, и про которую система виртуализации знать не может, что она свободна. И общепринятого термина для этого дела (памяти, которая раньше использовалась, а сейчас с точки зрения операционной системы, но не с точки зрения оборудования, не используется, и прочитать которую можно только через /dev/mem или /proc/kmem) на самом деле нет. Это не java-мусор. Но с моей XML-кой ядро сообщает гипервизору через balloon, что память не используется, и поэтому мусор не накапливается.

Объясняю на пальцах — у тебя в шкафу есть книги и старые газеты. Книги ты читаешь, старыми газетами топишь печку, застилаешь стол и прочее — короче, они тебе не особо нужны, но и выбросить нет повода. Если не появятся книги — тогда ты их выкидываешь, если нужно, чтобы было куда класть.

ОС работает с оперативной памятью точно так же. Есть те данные, что лежат в памяти и нужны по-настоящему. А есть те, что лежат там, но не особо нужны и если возникнет нужда, будут оттуда изъяты в пользу нужных.

Но вот ты собрался переезжать. Если ты просто скажешь грузчикам перевезти твои вещи, они сложат в ящики и книги, и старые газеты. Потому что они не знают, что тебе важно, и по умолчанию полагают, что важно всё.

Точно так же и ОС хоста, на которой работает виртуалка, обычно понятия не имеет, сколько памяти ей нужно под важное, а сколько под неважное. Только сумму и того, и того. Потому столько и выделяет.

Но ты можешь сказать грузчикам, чтобы они грузили только книги, а газеты оставили. И тогда будет меньше ящиков нужно на переезд.

Точно так же есть специальные плагины, которые позволяют виртуалке сообщать ОС хоста, сколько памяти нужно именно на важное, а остальное не хранить.

Короче косяк в софте? В LXC/LXD нормально с этим все?

Это не косяк, а так и должно работать. И насколько помню да, в случае с контейнерами распределение памяти работает лучше. Но там своих приколов хватает.

С контейнерами какие приколы?

Какие-то особенности, что проявляются при большом числе процессов из-за каких-то особенности в обработке cgroups ядром Linux. Точнее забыл.

Сколько должно быть процессов чтобы это заметить?

Много. Я об этом прочел в статье о высоконагруженном сервере.

Это на процессоре амд или Интел? Поколение процессора какое? Версия Линукс ядра?дистр какой?

На всех. Это не баг. Это особенность поведения.

Баг — это когда ОС работает не так, как должна.

А не тогда, когда она не соответствует твоим непонятно с чего взятым ожиданиям.

У всего есть свои ограничения и недостатки.

Linux Ate My RAM?

Но ты можешь сказать грузчикам, чтобы они грузили только книги, а газеты оставили.

Это ты сейчас предложил дисковый кэш отключить? Это вообще возможно в современном линуксе?

Дисковой кэш на HHD,разве он вытянет?

А дисковой кэш на жёсткий диске это норма? Жёсткий диск вытянет? Ведь там кэша может быть на гигов 10.

Тоесть htop устарел хотел сказать? Через какой тогда чекать?

Дисковой кэш на HHD,разве он вытянет?

Дисковый кэш в оперативной памяти.

А дисковой кэш на жёсткий диске это норма? Жёсткий диск вытянет? Ведь там кэша может быть на гигов 10.

Размер дискового кэша равен объёму свободной оперативной памяти. Посмотри ссылку, которую я дал выше.

Тоесть htop устарел хотел сказать? Через какой тогда чекать?

Нет, ничего такого я не хотел сказать, не знаю, с чего вдруг такие выводы.

Зачем в ОЗУ то складировать? Забивать ОЗУ только. Мб его как-то действие можно отключить?

Отключить нельзя, но можешь раз в секунду делать echo 3 > /proc/sys/vm/drop_caches от рута. Часть страниц остаётся закешированной и после этого, но тебе хватит.

Потому что это ускоряет дисковые операции во-первых, и совершенно не мешает прикладному ПО во вторых — если ППО понадобится больше памяти, данные из кеша будут сброшены.

Windows вообще использует кеш в оперативной памяти крайне агрессивно, фактически занимая попросту весь доступный объем.