RAM Disk in LXC not showing usage in PVE

[AWillUS]

Hey, been working on setting up a new PVE lab at home for multiple use cases incl. finally getting off my Windows Plex Server setup.

I have my initial basic cluster up and running with two nodes (one more to come soon) and been testing all sorts of LXC's and VM's to ensure I understand all I am trying to do before actually migrating over the production environments.

As part of my testing, I have been testing a RAM Disk mounted in a privileged LXC (default Debian 12 template) for a Plex Server's temporary transcoder location, and it works beautifully, saving SSD life and rapid initialization of the transcode session for live TV and HDHomeRun Prime FIOS Cable source.

However, this is where my issue arises, as the server amasses data in the RAM Disk auto mounted inside the LXC (12G of 16G allocated to the LXC), the usage does not show in PVE either for the LXC itself, the node or the cluster. Can anyone point me to why this might be as I can see this being an issue if I (or someone) ever were to use RAM Disks in a HA environment where the migration decisions could be affected by the "non showing memory consumption in PVE".

Screenshots for showing the usage of the RAM Disk inside the LXC (approx.. 50% ~ 6GB) and the PVE dashboard metrics for memory usage on LXC and Node at the same moment in time.

 

[Kingneutron]

Not sure why you didn't just use the existing /dev/shm ... ?

 

[AWillUS]

Not sure why you didn't just use the existing /dev/shm ... ?

So first up thanks, learned something today, did not know of /dev/shm as a concept (still learning Linux every day)

Second, a quick look into this, while I can see your point as this being a potential viable solution to the monitoring problem, it could pose another issue, where the application using /dev/shm for temp storage, in this case my Plex Transcoder service, might not limit itself to X Gb, which could introduce a new set of problems for the rest of LXC?

Note: It appears that the Plex transcoder does limit itself, at least in my current use test it seems to back off from filling out the allotted 12GB and start flushing the earlier recorded live stream when it hit some 85-89%, however one cannot trust all applications to be so nice.

Regardless, this still does not answer why the manually mounted RAM Disk usage does not show usage metrics in PVE,

 

[Kingneutron]

LXC is a bit weird, if you need real constraints I would move this application into a VM.

 

[AWillUS]

LXC is a bit weird, if you need real constraints I would move this application into a VM.

Yeah, I prefer LXC's due to the hardware passthrough limitations in VM's,

Also I did some further research into /dev/shm and it appears at least for a privileged container like this, that it can grab memory from the host/node itself and not actually the LXC allotted memory, this is an interesting issue as well. I get that privileged containers generally are not the way to go for real world production, but curious if this is also the case for unprivileged containers as well.

Ps. running a free -h command in the LXC actually yields the proper metric, this is getting weird

 

[AWillUS]

Couple of updates:
1: I tested with /dev/shm as the Plex Temp transcoder path, which works out of the box, so kudos on that suggestion, for others this is an easy approach and avoids any issues with fstab editing. It does however also not report memory usage in PVE dashboard.

2: It would appear that the node cli "free -h" as well as Plex Application itself actually do see the memory usage see screenshots. My guess is (someone with Desbian/Linux advanced experience know?) that while the data is stored in /dev/shm (or another RAM disk) it is not considered blocked/reserved and the system can still claw it back if needed or something similar to that? If not I think it would be very much a required metric to report to the PVE to ensure proper allocation of resources and potential cluster migration choices to be considered.

 

[Kingneutron]

You can try filing a bug report on the PVE tracker

https://bugzilla.proxmox.com/index.cgi