Has anyone tried setting their transcode directory to /dev/shm? I may be picking up a server with 72gb of memory (36gb /dev/shm), and it'll be dedicated to running only Plex. It seems a bit excessive, I know, but it's what the hosting company has offered me at a great price.
Seeing that Plex doesn't use much memory, but does a lot of writing to disk while transcoding, I'm assuming that writing the temporary transcode file straight to /dev/shm may speed up the process a bit.
Has anyone done this? If so, how were your results? And lastly, would you recommend against it?
Oddly enough, with it in /dev/shm I found I had to restart the server about once a week. After a bit it would struggle to transcode even simple things. Stranger still is that it didn’t appear to be a memory leak. This is on an i5 with 8GB RAM and a ZFS array with an L2ARC. I didn’t notice any obvious memory leaks by examining the location on /dev/shm and glancing at htop, but after a few times of it struggling I changed it back to default and the problem went away. I plan to try and debug the mess at some point, if I can, but I figured I’d at least share in case anyone runs across the same issue.
I’ve been running this way for about a year on my freebsd box (mfs tmp - same idea), also using zfs with 2G dedicated for cache.
The biggest benefit is it cuts out about 80% of your disk i/o during transcodes. Optimally with this setup I’m recording/transcoding/writing from memory to memory, and then letting zfs do it’s thing.
After having a nightmare of a time with the Plex plugin on FreeNAS I implemented ZFS on Debian instead. I’ve wondered if it was an issue with ZFS tuning, or the L2ARC but haven’t had the time to really dig into it. It’s good to hear it works well for someone. It only makes sense to me if you have the spare memory.
Fair enough Chuck, perhaps bringing up a good point. Since it won’t take much time to flip the setting I’ll give it a go and lodge the transcode directory in /tmp or maybe even /var/tmp for the fun of it.
The real kicker here is ZFS, in my opinion. I wonder how the ARC behaves when data starts swapping from /dev/shm (/run/shm on debian) vs /tmp or /var/tmp? I mean, it really shouldn’t make a difference, right? I dunno. I’m not an expert on ZFS or Debian’s memory management. My ARC is limited to leave about 4 GB of memory free and my transcodes rarely break 2GB… But I don’t really start watching it until it’s trashed. I haven’t even dug into Plex logging, but now that I’m yapping about it maybe I’ll find the time this weekend.
But on the zfs thing, it used to have an issue with freebsd using mfs(tmpfs) on the same system as zfs. Not sure when it was resolved, but I haven’t had any issues. I migrate between stable/current, wouldn’t be surprised if it wasn’t still a problem with freenas images.
Freenas is BSD. FreeBSD is just enough different at the PMS coding level to require #ifdef statements. p. I will look into it but I honestly haven’t touched BSD since the SunOS days.
Plex on FreeNAS was an absolute nightmare. Although it handles ZFS well nobody seemed to give a fudge about getting jails to work correctly, let alone plugins. I should also mention I run off a USB 3.0 stick and symlink /var and/tmp to the ZFS pool, so that’s why I chose /dev/shm. Not to get off topic though…
Thanks Chuck, but the problem seemed to be more with FreeNAS than Plex, IMHO. You had to do some real magic just to get it to work in a jail. The GUI and installation candidates struggled from version to version with how to link a share in your pool to the jail. Once the string for the directory inside the jail ended up being too long because of how convoluted it was and the GUI wouldn’t recognize it. Not to mention the version discrepancy with the plex pass version and the standard version and the fact that it was named something ridiculous like “Plex Media Server - Plex Pass”. You had to manually download and install it inside the jail from scripts because what was on the repository was so old the clients would complain. Just a real mess.
As I understand FreeNAS, you are essentially forced to put things in their “jail” (containers).
It makes zero sense but if that’s how they want it, it is their product after all.
With that, I know nothing more about it.
Sure I’ve coded a long time in Unix but haven’t touched freebsd itself other than install and immediately delete the VM at the shock.
run mount in a terminal, I’m pretty sure they’re all just mounting the same resource and exporting it to userland in different locations. if it isn’t /dev/shm then it’s going to be nonvolatile storage. I would assume /var/tmp is going to be disk so it persists between reboots.
Pretty much anything in /var is in the root.
That’s why I had to show folks how to customize their configuration in systemd and move PMS out of there. (Small SSDs can’t handle large media libraries)
For me my mounts are a bit more off since I’m running root off a 15GB USB stick.
dev is devtmpfs, and has a max size.
/run is tmpfs and has a max size.
/dev/shm has it’s own tmpfs, but is just a link to /run/shm
/var and /tmp are mapped to the ZFS pool.
So setting it to /tmp or /var/tmp puts it soely to ZFS to handle, which uses ARC and L2ARC to reduce excess IO. Putting it to /dev/shm is a ramdisk that hits to swap, which is on the 15GB flashstick root resides on. I previously elected to specify as /dev/shm because Oracle has issues with /run/shm, but that’s probably irrelevant.
Because of ZFS I never really saw a notable improvement to performance specifying shm over tmp, I think. Additionally I wondered how ZFS would react if something started eating up memory, and was wary of putting it to shm… But I figured I’d give it a go. In it’s default location or specified anywhere in /tmp or even /var/tmp it seems stable for months. It wasn’t until I put it to ramdisk that I had problems. Now that I’m on about it I’ll try and figure out exactly what the issue is.
It seems like you have a really complex configuration. Just to ask, is there any way to simplify it? It seems like you’re going through a lot of pain which shouldn’t be a “First World” problem.
Agreed. As a firm believer in keeping it simple, I had perhaps stupidly installed debian to boot from a USB stick and then installed ZFS and made the data pool. I then had to move directories like /var onto the data pool as the usb stick wasn’t large enough. Needless to say if the data pool went down then so would boot. I remedied the issue by tossing the usb stick for a flash drive of larger size so I don’t have to symlink /var to the ZFS data pool.
I also found that the issue was resolved by reducing the size of the ARC a bit. The issue cropped up again when I was trying to transcode a seriously large file. It didn’t roll into swap, but it came close. I can only think this caused a problem for ZFS in some fashion. Why the issue persisted after transcode was over I don’t understand.
On /tmp or /dev/shm makes no difference it seems. Apparently if I want to transcode a video over 80GB’s I’ll need to buy more RAM, as I’d rather not go below 7GB on the ARC. I’m proud to say that the current setup is working great as a NAS, a caching proxy for steam and a plex media server. Until my next post, at least…
