PVE incorrectly displays RAM consumption by Linux virtual machines

emptness

Member
Aug 19, 2022
105
6
18
Hello everyone!
Recently I noticed that in the Summary of some VMs, RAM consumption is almost 100%.
Although if you look in the guest system, the memory consumption is much less.
I understand that the "avail MEM" indicator is not taken into account in the pve interface.
At the same time, gemu-guest-agent is installed.
What could be the problem?
1694696397199.png
1694696457785.png
1694696501297.png
 
the buffered/cached memory is in use by the VM, it's just counted as available inside the VM since it can be released.
 
this is normal - see linuxatemyram.com
 
And why then this functionality in the web interface?
Because this is the correct value. The memory IS ACTUALLY USED, therefore it is shown as used. Please see the link and how memory actually works. Windows does show you only the avail ram, therefore most (windows) people think that this is norm, yet it is actually not, it just shows it like this.

Also: This topic has been discussed plenty of times, so please search the forum before posting another incarnation of the same question.
 
A good example of this being correct is within the screenshots provided.
The htop image shows Yellow all the way up to 91% (ish) but reports the green as 1.01G/3.88G... others may correct me... but the way I understand it. the green is your live processes, blue is tempfs (swappable) and yellow is your filesystem/system caching??!?

It gets even more exciting when you wonder what mem ballooning is all about... however, I hope this provides a little more insight into what your previous answers have been about.
 
  • Like
Reactions: LnxBil
Because this is the correct value. The memory IS ACTUALLY USED, therefore it is shown as used. Please see the link and how memory actually works. Windows does show you only the avail ram, therefore most (windows) people think that this is norm, yet it is actually not, it just shows it like this.

Also: This topic has been discussed plenty of times, so please search the forum before posting another incarnation of the same question.
I tried to search for topics with the information I needed on the forum. But all the topics I've found boil down either to Windows and Balloon or to the problems of high zfs consumption. Therefore, I created a theme.
In my opinion, this is not entirely true.
1. Why does Windows VM with driver Balloon show information comparable to the guest OS, but VMLinux does not?
2. I understand how memory is used in the OS, but cached memory does not mean that the service is running out of memory. As a result, the service is working fine, and proxmox shows that it has a critical lack of memory. How does this information help me?
This is done only in order to understand where the hypervisor can take memory for the needs of other VMs, and from where it can't?
 
1. Why does Windows VM with driver Balloon show information comparable to the guest OS, but VMLinux does not?
Because PVE is just showing what the QEMU guest agent implementation of the GuestOS is reporting to it. Windows reports wrong numbers (counting RAM used for caching as "free" and not as "used") as so does the guest agent and PVE is then showing this. Linux with guest agent reports the real numbers (where RAM used for caching is "used" and not "free").
And both numbers only show the vRAM, not the used physical RAM. For that you have to look at the "RES" of the KVM processes column of htop.
Not that uncomman that a VM with 4GB max RAM which the guestOS is only using 1GB is actually consuming 5GB or so of the hosts physical RAM as there is virtualization overhead and so on.

2. I understand how memory is used in the OS, but cached memory does not mean that the service is running out of memory. As a result, the service is working fine, and proxmox shows that it has a critical lack of memory. How does this information help me?
PVE has no idea how that RAM is used by the guestOS. Only the guestOs knows this. All a hypervisor cares about is how much RAM is in use or free.
Also only the guestOS can drop caches not the PVE host. so from the point of view of the hypervisor its correct that 91% are used and only 9% free.
If you want to monitor your guests there are way better tools for this (for exmaple have a look a zabbix, grafana, checkmk, ...
 
  • Like
Reactions: emptness and LnxBil
Because PVE is just showing what the QEMU guest agent implementation of the GuestOS is reporting to it. Windows reports wrong numbers (counting RAM used for caching as "free" and not as "used") as so does the guest agent and PVE is then showing this. Linux with guest agent reports the real numbers (where RAM used for caching is "used" and not "free").
And both numbers only show the vRAM, not the used physical RAM. For that you have to look at the "RES" of the KVM processes column of htop.
Not that uncomman that a VM with 4GB max RAM which the guestOS is only using 1GB is actually consuming 5GB or so of the hosts physical RAM as there is virtualization overhead and so on.


PVE has no idea how that RAM is used by the guestOS. Only the guestOs knows this. All a hypervisor cares about is how much RAM is in use or free.
Also only the guestOS can drop caches not the PVE host. so from the point of view of the hypervisor its correct that 91% are used and only 9% free.
If you want to monitor your guests there are way better tools for this (for exmaple have a look a zabbix, grafana, checkmk, ...
Many thanks for the detailed answer!
I have imbued myself with this philosophy and I have reached the stage of acceptance)
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!