this appears to be much ado about nothing, the memory being showed used is total application virtual memory that is mapped in the kernel, its not how much memory is using of your /dev/shm.
at the very top of your memory picture, it says memory AVAILABLE, which is showing plenty in either case.
applications request/allocate ram, to run the application processes.
the kernel automagically determines what is actively in use vs stale or idle code, and generally stores that in the page file.
/dev/shm has nothing to do with application memory, applications don’t even see /dev/shm, other than as storage.
the system sets the 50% of physical ram as the size of the devshm primarily so applications can have some kind of shared memory/io.
using /dev/shm as transcode or any other temp storage is really not its purpose, but we do it anyway because it generally avoids unnecessary writing to ssd.
this is the ONLY reason to use /dev/shm. transcode to ram will not speed up your transcodes unless there is something else that is seriously broken on your system.
if something or many things fill up the /dev/shm then the kernel will start to store inactive files out to the page file.
if physical ram and page file completely fill, then the kernel will start killing processes that are hogging ram.
At this point, I don’t think /dev/shm is being filled up anyway (contrary to my first post about this). Given all the things above, why does the kernel allocate up to 25GB (based in Cockpit) for plexmediaserver? Is allocation the same as reserving in Linux?
The reason why I’m asking all these is because I’m currently having issurs with my Roon Core server that’s on the same NUC as my plex. Starting last week, it started not responding and its services take up CPU and all of RAM/Swap until OOM killer kicks in to kill its process. I was wondering if Plex using /dev/shm has anything to do with that but the when I see the RAM utilization in /var/log/messages when this happens, I don’t even see Plex consuming a significant amount of RAM.