Incorrect RAM usage in webui for VM

[ca_maer]

Hello,

It seems the ram usage in the webui is incorrectly reported in our case. The VM is an ubuntu 20.04. The host is running ZFS. Ballooning is off. This is happening for all of our VMs.

Here's a picture of the webui:


and here is free inside the VM

              total        used        free      shared  buff/cache   available
Mem:           3983         308        1877          24        1797        3583
Swap:             0           0           0

Any ideas what might cause this ?
Thanks

 

[matrix]

I think 4 GiB not enough for Ubuntu 20.04 specific if you use it for web server or something like that

 

[ca_maer]

I think 4 GiB not enough for Ubuntu 20.04 specific if you use it for web server or something like that

According to free it seems to be plenty. There is 3.5GB of available ram and no OOM has been called.

 

[Joris L.]

According to free it seems to be plenty. There is 3.5GB of available ram and no OOM has been called.

No worries, memory requirements can often be configured and are highly dependent on the load on the web server.
I run a few vm <= 1GB of RAM running multiple services. No problems, even without swap.

 

[BobhWasatch]

Do you have the qemu guest agent installed?

 

[ca_maer]

Do you have the qemu guest agent installed?

I do

 

[Joris L.]

Hello,

It seems the ram usage in the webui is incorrectly reported in our case. The VM is an ubuntu 20.04. The host is running ZFS. Ballooning is off. This is happening for all of our VMs.

Here's a picture of the webui:
View attachment 17768

and here is free inside the VM

              total        used        free      shared  buff/cache   available
Mem:           3983         308        1877          24        1797        3583
Swap:             0           0           0

Any ideas what might cause this ?
Thanks

Notice how available is 3583 (3.59 rounded) wich matches the 3.59 out of 4.00 GB, an unusual way of representing memory usage by Proxmox.

 

[ca_maer]

Notice how available is 3583 (3.59 rounded) wich matches the 3.59 out of 4.00 GB, an unusual way of representing memory usage by Proxmox.

Right. Could mean Proxmox count available ram as used instead of free

 

[Joris L.]

Right. Could mean Proxmox count available ram as used instead of free

it is a classic in the world of computing

 

[ca_maer]

it is a classic in the world of computing

I understand what you mean but Proxmox should report the same memory usage as how free does. When looking at the webui you might think the ram usage is at 90% while it's really just at around 14%. There's might be more to it in the background which is why I created a thread. I'm trying to understand the reasoning here.

 

[Joris L.]

I understand what you mean but Proxmox should report the same memory usage as how free does. When looking at the webui you might think the ram usage is at 90% while it's really just at around 14%. There's might be more to it in the background which is why I created a thread. I'm trying to understand the reasoning here.

Just checked, on this machine the webUI reports all correctly as on the commandline. I must add i experienced the same issue as you observerd. With me memory usage was wildly overreported, close to 25GB while just 5GB was in use. I assume this to have been because of hugepage configuration. I will revive it in the future, now it is not enabled an memory is reported as is.

 

[ca_maer]

Just checked, on this machine the webUI reports all correctly as on the commandline. I must add i experienced the same issue as you observerd. With me memory usage was wildly overreported, close to 25GB while just 5GB was in use. I assume this to have been because of hugepage configuration. I will revive it in the future, now it is not enabled an memory is reported as is.

What is the OS of the guest ?

 

[ca_maer]

The issue is still present. Using Ubuntu 20.04 with qemu guest agent installed.



Inside the VM:

              total        used        free      shared  buff/cache   available
Mem:           8079         679         323          42        7076        7240
Swap:             0           0           0

It's like if the Proxmox webui count the buff/cache column as used ram

 

[BloodyIron]

I find that Proxmox RAM reporting is never accurate, and it's quite useless to be honest. I build a new VM and haven't done anything with it. 6GB RAM capacity, only using about 400MB, and qemu-guest-agent installed (Ubuntu 20.04 in this case) and it reports over 5GB of RAM used. And that 400MB used includes cache and such, and this is right after a reboot.

I really want the developers to revisit how RAM is reported in the webgui, and if they want to clear up any ambiguity around it, maybe report all the different stats for RAM? Not just lump it into one figure? It's really very useless and unreliable in its current form. I just don't even bother with it any more, why even have it if it's unreliable? Bleh.

 

[fabian]

see the admin guide:

Even when using a fixed memory size, the ballooning device gets added to the VM, because it delivers useful information such as how much memory the guest really uses. In general, you should leave ballooning enabled, but if you want to disable it (e.g. for debugging purposes), simply uncheck Ballooning Device or set

balloon: 0

in the configuration.

without a ballooning device, PVE can (and will) simply report the used memory of the Qemu process. with a ballooning device, total - free will be reported (since cached/buffered memory is treated differently by different guest OSes, this might not match what the OS reports as 'free').

 

[fabian]

also, the ballooning interface has no notion of memory buffered/cached/easily freeable by the guest OS, since that happens on the next layer. total - free is all we can report via that interface

 

[spirit]

buff/cache memory is really used by the vm, and cannot be used by other vms.

So, I think you just need to think that "memory usage" on the gui, is memory usage from the hypervisor side/view. (and that's great, if you want to list vms ordered by memory usage, or do some kind of balancing,...).

if you need to monitor vm memory, you can use classic tools like grafana,prometheus,influxdb,cacti,nagios,.... in the vms directly.

 

[ermanishchawla]

Hello,

It seems the ram usage in the webui is incorrectly reported in our case. The VM is an ubuntu 20.04. The host is running ZFS. Ballooning is off. This is happening for all of our VMs.

Here's a picture of the webui:
View attachment 17768

and here is free inside the VM

              total        used        free      shared  buff/cache   available
Mem:           3983         308        1877          24        1797        3583
Swap:             0           0           0

Any ideas what might cause this ?
Thanks

It is correct only. The memory showing available is actually a reclaimable space by kernel.
Read the article attached for your reference. It is true for Ubuntu/RHEL/CentOS

 

[paulie420]

So I've been reading along, trying to understand. From what I gather the 'Memory Usage' displayed in the PVE web GUI is on the Proxmox server side - or what the machine RUNNING that VM is using; not what the VM within itself is using... I tried to read the memory_usage.pdf file to understand more but I'm still a tad confused.

Just wanted to post that I'm still seeing this in 2023 - on several differe Linux flavors; the one in the photo is Ubuntu-Server.

pAULIE42o
. . . . . . . . . . .

 

[Dunuin]

You need to wrap your head around the difference between "free" and "available". "free" is RAM that isn`t used at all. "Used" is RAM that is used in any way. "Available" RAM is RAM that is in use but could be quickly freed up by the guest OS when needed, so it is still kind of available.
What mosts Guest OSs will show is the "available" RAM and not the "free" RAM but you just interpet that as some kind of free. What PVE will show for Linux Guests with QEMU guest agent is "used" and "free" RAM. For Windows Guests with QEMU guest agent PVE will show "available" RAM. For OSs without a installed guest agent it will show the RAM usage of the KVM process as a fallback, as PVE can't query the RAM usage from the guest OS.
See for example: LinuxAteMyRAM.com