Plex Transcoding on RAMDisk

Hey all,

 

I just recently stumbled on an article that made me feel like I was back in 1994 again and it was about RAMDisk's and how much faster they are than SSD's.  I decided to try it out and indeed the RAMDisk I made benchmarked at over 5 GB/s read and 6 GB/s write speeds (my SSD's get 250+ MB/s).  It got me thinking, I have this home media server with an abundance of extra RAM (32 GB total) and I'd like to find a way to utilize that.  Then I was wondering what exactly I'd do with a RAMDisk and I was considering if this would be a viable transcoding drive for Plex.  I've Googled it, but haven't found much information especially as it pertains to Plex.

 

Currently, I don't have many issues with Plex and network speed isn't one of them, so I'm not looking to "speed" things up necessarily.  What I'm more interested in is whether or not this could solve the issue that no matter what I do, I can't watch videos streamed by Plex and continue downloading and processing data in the background.  I'm almost positive that the reason the video freezes on me when this happens is because I'm running SATA drives and if I had SAS drives that would allow simultaneous read/write, I don't think this would be an issue.  But, instead of purchasing a SAS controller card at a few hundred bucks and then spending hundreds more on SAS drives, what if I just used all this extra RAM I have and make a RAMDisk?

 

I'd be very interested in hearing if anybody is currently using this, how well it works, etc.  I'd also like to know how transcoding with Plex is done, more specifically, does it do a frame at a time and then push it to the device?  How big would the RAMDisk need to be for it to be efficient?

 

I appreciate any input in this matter!

 

It depends what transcoding you're wanting to speed up. Many transcoding operations are *very* CPU-limited, meaning the CPU is the bottleneck, not any other part of the system. Granted, this is more true for video than it is for music, but for the most part you could probably speed up your storage system and find it wouldn't matter one bit.

It also might not make any sense to speed up the transcoding, if Plex's on the fly transcoding we're talking about. For example, if your server can transcode video at 2x realtime (say), it can already keep up with the demands of any single media player. Being able to transcode a single stream at 4x real time makes no difference whatsoever.

Sequential transfer rates sound really impressive for RAM disks, but again they're pointless for this sort of application. The bitrate of a raw CD stream is 1440 kbits/sec, or 180KB/sec. Any compressed 2-channel, 16-bit 44kHz audio will by definition be less than that. Your SSD can stream that data at least a *million* times faster than that; what's the point of a RAM disk at that point?

Bluray's maximum bitrate is something in the region of 60Mbit/sec, or call it 7.5MB/sec. That's a paltry data rate for a modern computer to keep up with, and again by definition any compressed media will have a lower rate. A cheap software RAID array of mechanical disks can easily outdo that by a factor of 10 or more and your SSD is 33 times faster. For transcoding, there's no point in being able to shovel the data at the CPU any faster as it simply can't keep up.

RAM disks are a pain in the bum, to be honest. They excel as temporary scratch space for working on data with next to no access time hit, but they're hopeless otherwise. As soon as you shut the machine down, the RAM disk's contents are lost, and have to be repopulated the next time the system starts up.

IMHO, if you wanted to make use of the extra RAM on your home server, a better approach might be to get into virtualisation.

I have a Vsphere whitebox at home ("whitebox" is the term given to a server that's built from comparatively cheap commodity hardware rather than anything that's expensive and on VMware's hardware compatibility lists). It's quad-core Ivy bridge (i5-3470) system with 16GB of RAM, a boot/datastore SSD and a handful of 3TB drives; it runs the free version of Vsphere 5.1 (register with VMware and they give you a key to turn the trial version into something permanent), but it could quite easily be built on top of Microsoft's Hyper-V or something open-source like Xen. I chose Vsphere as that's what I wanted to learn at the time.

On there I run an instance of FreeNAS (with the onboard SATA controller handed over to that VM), several instances of Ubuntu 12.04 for various purposes (including one that runs Plex server), an instance of WinXP for a couple of bits and bobs I'm playing with that are Windows-only and a small cluster of virtual machines for work.

Doing things this way means I've been free to pick and choose between functions. I like ZFS as a filesystem, so something BSD-based made a lot of sense and FreeNAS was simple to get up and running. However, a lot of other software runs on Linux; if I'd dedicated the entire machine to FreeNAS, I would have been out of luck in running any of that.

Another nice side-effect is the segregation between functions. For example, nothing I do to the VM running Plex can affect my FreeNAS install; I can't bork my data just because I much up something in Ubuntu. Similarly, I can feel free to fire up new VMs for work or whatever that I can trash if I make a complete mess of them, and it affects nothing else.

The hardware cost no more than a pre-built Atom NAS box, consumes about the same amount of idle power (Ivy Bridge idles at single-digit Watts; it's damn impressive) and offers far more flexibility in what I can do with the system. Instead of hoping everything plays nicely with one another under a single OS, I have over a dozen servers up and running that all do their own thing. The main cost over a NAS is my time; I had to spend the time to set everything up and so forth.

The reason RAM is important is that every instance of a VM incurs some overhead. I'm running many instances of different (and sometimes the same) operating system, which isn't free. However, RAM is cheap, and ~100MB or so per instance of (say) Ubuntu server is something I'd planned for by building with 16GB.

The problem with virtualisation is it really has to be planned from the beginning. It's hard to take a machine that already has data on it and turn it into a VM factory (where does the data go in the meantime?). It's also hard to take just any old machine and turn it into a Vsphere system; there are certain hardware features that are very desirable for running Vsphere, and not all processors, chipsets and motherboards support them.

Like I said, it cost me some time to set up, but it's opened up a world of possibilities that I wouldn't otherwise have.

So I read your topic and decided to try it out. Just set the transcoder temporary directory to the mounted tmpfs and it's working smoothly.

If  you're not familiar with ramfs / tmpfs here's a good read:

http://www.thegeekstuff.com/2008/11/overview-of-ramfs-and-tmpfs-on-linux/#more-251

I'd recommend a tmpfs.

The transcoder, it seems, stores many .ts files in different directories for each show being watched. I believe it cleans up after itself after the video finishes. I of course made my initial tmpfs 1024m so it's taking the better part of a movie to see what happens when it reaches the limit. 

I read tmpfs will pour over into swap once it's full, I really hope plex will just cleanup watched ts files out as the tmpfs fills up.

@Smegheid - your post was an interesting read, the reason I'd continue to use a ram disk for transcoding is to remove unnecessary read and writes on my SSD.

EDIT:

well finally played to the 1GB mark, plex clears the tmp dir and my 1GB tmpfs is empty again, the transcoder kicks off and hangs as the player was still buffering & w/ cpu utilization but nothing written to the tmp dir.

Some purge logic needs to be introduced to manage the transcoder's temp directory if we want to have a limited directory size.

TBH it would be nice to not have to write the transcoded data back to disk if we don't have to. For multi-user setups that come under concurrent load this could prove to be quite useful.

Thanks for the responses and very solid info!

@Smegheid - I really don't have any need to speed things up per se.  I guess what I'm trying to say is my primary issue isn't speed at all, but instead it's doing too much disk access at one time or at least I think that's the problem :).  Here's my setup:  i7-3770k overclocked to 4.2Ghz, MSI Z77A-GD65 mobo, 32 GB of RAM, PowerColor 7870 Myst Edition, Corsair SATA III 128 GB SSD's (for the OS which includes my installed programs) and my video drive is a 3 TB USB 3.0 external Seagate 7200 rpm drive.  When I'm downloading something and I'm watching a video at the same time, it's fine until the download gets processed and is being extracted.  When that happens, my video that I'm transcoding freezes and won't recover unless I restart the video from scratch after the entire process is over.  So what I was wondering is if I use a RAMdisk as the transcoding destination, would this eliminate the freezing?  Currently my transcoding drive is setup to transcode to the external 3 TB drive (which again is what I'm playing the video from as well as where the downloaded data is being written) although I've also had it transcoding on the SSD and there was no difference on the freezing.  I suppose this could also be an issue with the processor, but that just seems so unlikely considering I've ran this thing through seemingly much higher loads in benchmarking and it hasn't hiccuped or done anything weird.  It just seems like a disk access issue and so I was wondering if a RAMdisk would offload that stress on these drives.  I do have a bunch of other hard drives, none RAIDed, just random old drives that I've thrown in here and I haven't tried putting the transcoder on any of those either to see if it would help.  I suppose I could do that to test it as well.  I just figured that since I overdid it on the RAM with 32 GB and I've maybe used at most, 10 GB of that at any given time that I could utilize that extra RAM with the RAMdisk and save some money instead of buying commercial-grade SAS equipment.  I definitely am interested in transcoding to multiple devices simultaneously at some point in the future as well.

@Vulcanworlds - I never really thought about it from the perspective of conserving read/writes on the SSD to prolong longevity, but that's a good point. :)  I have a trial edition of Dataram's RAMdisk and it's a great program, but only allows for a max of 4 GB to a single disk.  I was wondering whether or not if you're transcoding a 13 GB MKV file if that would mean that I'd at least need a 13 GB RAMdisk to effectively transcode or if I'd need more RAM allocated for that.  I'm totally willing to purchase the software because it would only be $20 and I like the fact that you can have Windows mount the drive on startup, yet you can still throw away the data after each reboot and not commit it to the saved image file.  When you say some "purge logic needs to be introduced" I believe you're saying that it doesn't automatically purge the transcode directory, correct?  I noticed a while back when the transcoding was still setup on my SSD that WinDirStat showed a huge amount of data being eaten up by the transcoding directory, so I suppose that would be the case.  With this program, it'll theoretically throw away that data every reboot, but that doesn't help if the thing never reboots, which is the goal...  Maybe there's some Windows scripting that could be done on this to automate clearing the directory out?

Again, thanks for the helpful info!  Whenever I get a plan figured out and have more time, I'd be happy to post my findings on here as well.

I’ve done it in Archlinux and it doesn’t really is worthy because the bottleneck would not be your HD , I think SATA III is 3 gbps IIRC so split it in a half, so 1,5 per up and down . Still enough. As plex uses ffmpeg for all things, and it relies on your CPU speed , that is the bottleneck, do a test, encode a file manually with ffmpeg with x264 and mp3 or AAC and that is exactly what plex does to transcode. What I’m frying to argue is that a bluray movie is 40 Mbps < 1,5 gbps so the drive wouldn’t be a bottleneck issue AFAIK.


If you want to preserve read/write cycles in SSD to prevent isolation then is a good choice but you need at least 16-32 Gb of ram, because tmpfs uses only half of your ram at most, so if plex is transcoding and tmpfs wants out of space then your transcoding session aka your movie and your joy will end suddenly.


Cheers.

@jvillanova - I wouldn't even call this a bottleneck issue really.  I have no speed concerns for wanting to do this.  It's a matter of figuring out if my HDD/SSD are under too much stress from read/writes and whether or not a RAMdisk will solve that and preserving read/write cycles would be an added benefit.  I understand that the CPU is what does the heavy lifting on the transcoding process :)  Also SATA III is 6 Gbps theoretical.  On my SSD I see real-world speeds around 250 Mb/s (2 Gbps) sequential and 150 Mb/s (1.2 Gbps) random.

Maybe I should just forget about it and build a 21 Tb SuperNAS like Linus did... 

Thanks for the responses and very solid info!

@Smegheid - I really don't have any need to speed things up per se.  I guess what I'm trying to say is my primary issue isn't speed at all, but instead it's doing too much disk access at one time or at least I think that's the problem :).  Here's my setup:  i7-3770k overclocked to 4.2Ghz, MSI Z77A-GD65 mobo, 32 GB of RAM, PowerColor 7870 Myst Edition, Corsair SATA III 128 GB SSD's (for the OS which includes my installed programs) and my video drive is a 3 TB USB 3.0 external Seagate 7200 rpm drive.  When I'm downloading something and I'm watching a video at the same time, it's fine until the download gets processed and is being extracted.  When that happens, my video that I'm transcoding freezes and won't recover unless I restart the video from scratch after the entire process is over.  So what I was wondering is if I use a RAMdisk as the transcoding destination, would this eliminate the freezing?  Currently my transcoding drive is setup to transcode to the external 3 TB drive (which again is what I'm playing the video from as well as where the downloaded data is being written) although I've also had it transcoding on the SSD and there was no difference on the freezing.  I suppose this could also be an issue with the processor, but that just seems so unlikely considering I've ran this thing through seemingly much higher loads in benchmarking and it hasn't hiccuped or done anything weird.  It just seems like a disk access issue and so I was wondering if a RAMdisk would offload that stress on these drives.  I do have a bunch of other hard drives, none RAIDed, just random old drives that I've thrown in here and I haven't tried putting the transcoder on any of those either to see if it would help.  I suppose I could do that to test it as well.  I just figured that since I overdid it on the RAM with 32 GB and I've maybe used at most, 10 GB of that at any given time that I could utilize that extra RAM with the RAMdisk and save some money instead of buying commercial-grade SAS equipment.  I definitely am interested in transcoding to multiple devices simultaneously at some point in the future as well.

@Vulcanworlds - I never really thought about it from the perspective of conserving read/writes on the SSD to prolong longevity, but that's a good point. :)  I have a trial edition of Dataram's RAMdisk and it's a great program, but only allows for a max of 4 GB to a single disk.  I was wondering whether or not if you're transcoding a 13 GB MKV file if that would mean that I'd at least need a 13 GB RAMdisk to effectively transcode or if I'd need more RAM allocated for that.  I'm totally willing to purchase the software because it would only be $20 and I like the fact that you can have Windows mount the drive on startup, yet you can still throw away the data after each reboot and not commit it to the saved image file.  When you say some "purge logic needs to be introduced" I believe you're saying that it doesn't automatically purge the transcode directory, correct?  I noticed a while back when the transcoding was still setup on my SSD that WinDirStat showed a huge amount of data being eaten up by the transcoding directory, so I suppose that would be the case.  With this program, it'll theoretically throw away that data every reboot, but that doesn't help if the thing never reboots, which is the goal...  Maybe there's some Windows scripting that could be done on this to automate clearing the directory out?

Again, thanks for the helpful info!  Whenever I get a plan figured out and have more time, I'd be happy to post my findings on here as well.

I'd think your bottleneck is the USB 3.0 drive, put one of your spare hdd's in the box and set that as the transcoding directory. With it being the only I/O for that disk, you should be better off than having the transcoding write to the external hdd. Or, use a spare hdd as the download destination or extract destination. It'd be better to have 1 disk be read from while writing to another rather than your current setup which is attempting to read 2 different files (the archive and the file to transcode) while attempting to write 2 different files (the transcoded data & the extracted data) all over the same USB port. Sounds like a good recipe for some I/O blockage.

It sounds like you're running windows, have you watched your drive I/O at all? Task Manager > Performance Tab > Resource Monitor

In my experience, my 3770k @ 4.5 seems to handle transcoding 2 different 1080p movies simultaneously to the same 1 TB wd black sata III drive haven't really tried anything past that, though cpu utilization wise it seems like maybe 3 is all I'd manage.

Technically you're correct about the ramdisk size. I'm thinking plex doesn't clear the transcoding directory until the file finishes playing or (a guess) you navigate back to the library. So, if you had enough space in your ramdisk for the entire transcoded file it should work without freezing & crashing PMS. If you want, try it out with a 20gb ramdisk and leave the other 12gb for windows. As long as you've got a single user or multiple users aren't all watching movies you may be okay.

The purge logic I mentioned is something that the plex developers should / would need to implement such that the transcoded directory only holds on to the previous few minutes you just watched rather than from the beginning of the file.

@Vulcanworlds - I offloaded the transcoding directory for Plex to a spare drive that I just got.  It's a 2 TB drive with a bunch of reallocated sectors, so if it fails, no big loss.  I'll have to see how this goes, but I'm a bit skeptical of whether or not this will help.  The logistics of how data flows in from my downloads and then becomes available in the Plex library might be impossible to solve.  I don't see how I can get the data downloaded, uncompressed, moved to the library, but yet play from that same library simultaneously without encountering issues.

For instance, say you're using Sickbeard/Couchpotato/Sabnzbd and you have them all installed on your local disk C:.  By default they download to a directory on C:, but you can of course change that download destination to a different drive like V:\.  Now on V:\ you want Plex to read that as your library so you set it to the directory there.  Now say you have another drive that you set as your transcoding drive T:\.  Now you have something downloading and you watch something at the same time so it's downloading to V:\ and you're watching a transcoded file, it's still accessing the V:\ drive for your video and then trasncoding it to T:\ right?  Eventually the download gets done and it needs to extract and process, so it's doubling the reads and writing to V: as well, correct?  Even if you left Sab to download to your C:\, you'd still need to eventually move it at some point to the V:\ drive to make it available to the Plex library, which would still be causing stress on the disk if you're trying to watch something at the same time.  After the download completes, Sab needs to process the file and extract it, potentially repair it with parity, etc. or am I missing something?

It just seems like there's no way to get around the disk that houses the library on it from being accessed by multiple sources both reading and writing simultaneously, which is why I was considering going with SAS drives for that, but of course those are so crazy expensive.  I thought potentially using the RAMdisk would at least eliminate the stress caused to the disk by transcoding, but I think the bigger issue is simultaneous read/writes...

Ugh my head is spinning...

EDIT:  What about RAID'ing the drive that the Plex library resides on?  If I put those in a RAID that would increase the bandwidth and cut the read/writes in half correct?

@Vulcanworlds - I offloaded the transcoding directory for Plex to a spare drive that I just got.  It's a 2 TB drive with a bunch of reallocated sectors, so if it fails, no big loss.  I'll have to see how this goes, but I'm a bit skeptical of whether or not this will help.  The logistics of how data flows in from my downloads and then becomes available in the Plex library might be impossible to solve.  I don't see how I can get the data downloaded, uncompressed, moved to the library, but yet play from that same library simultaneously without encountering issues.

For instance, say you're using Sickbeard/Couchpotato/Sabnzbd and you have them all installed on your local disk C:.  By default they download to a directory on C:, but you can of course change that download destination to a different drive like V:\.  Now on V:\ you want Plex to read that as your library so you set it to the directory there.  Now say you have another drive that you set as your transcoding drive T:\.  Now you have something downloading and you watch something at the same time so it's downloading to V:\ and you're watching a transcoded file, it's still accessing the V:\ drive for your video and then trasncoding it to T:\ right?  Eventually the download gets done and it needs to extract and process, so it's doubling the reads and writing to V: as well, correct?  Even if you left Sab to download to your C:\, you'd still need to eventually move it at some point to the V:\ drive to make it available to the Plex library, which would still be causing stress on the disk if you're trying to watch something at the same time.  After the download completes, Sab needs to process the file and extract it, potentially repair it with parity, etc. or am I missing something?

It just seems like there's no way to get around the disk that houses the library on it from being accessed by multiple sources both reading and writing simultaneously, which is why I was considering going with SAS drives for that, but of course those are so crazy expensive.  I thought potentially using the RAMdisk would at least eliminate the stress caused to the disk by transcoding, but I think the bigger issue is simultaneous read/writes...

Ugh my head is spinning...

EDIT:  What about RAID'ing the drive that the Plex library resides on?  If I put those in a RAID that would increase the bandwidth and cut the read/writes in half correct?

A couple of things:

1) Raid'ing your drives won't necessarily increase the available bandwidth to your media. It really depends on how it's setup.

2) Unless I miss understood, it seems like your media and your download path are on your external hard drive. Is that correct?

If so, you mentioned your external media drive is USB3, but is it plugged in to a USB3?

If it is on an external hard drive, that could be your bottle neck/ From my experience with external drives (which is not much), transfers over USB usually deteriorate if multiple read/write are occuring on the same drive. 

What I would suggest is that you download your media to your SSD and then manually transfer them to your external later, which is a hassle, but could be done automatically with a script.

Some purge logic needs to be introduced to manage the transcoder's temp directory if we want to have a limited directory size.

TBH it would be nice to not have to write the transcoded data back to disk if we don't have to. For multi-user setups that come under concurrent load this could prove to be quite useful.

Running Plex Media Server from a machine with fairly intensive operations on the filesystem I really like running transcoder reads/writes on a tmpfs. I've been doing this for a little while now. It all runs smoothly, but I do need to restart playback if the tmpfs fills up. So that's for anything where the quality after transcoding is still fairly high and the file is lengthy. (say, a 1080p 3 hour movie gets transcoded to a high bitrate 720p)

I see no reason why Plex would hang on to older parts of the transcoding session. It doesn't seem to influence seeking much. Can't really think of another reason they would be kept in the first place. Would love to hear more reasons if there are any, though.

So yes, I think it would be great if space would get purged/recycled. Alternatively it would also be great to simply have a configurable space limit per transcoding session. (Or a collective limit for all sessions, but that seems more error-prone.)

@thejixn0r - if it's setup in a RAID-0, then it's just striped across all drives, right?  That should theoretically increase the bandwidth unless I'm mistaken.  Guess it really doesn't matter since my largest media storage drives are external and I'd need to rip them out of the enclosures.  Also, yes it's on a 3 TB Seagate 7200 RPM USB 3.0 drive.  The drive typically sees sequential read/writes around 145 MB/s when transferring to/from my SSD.  Not sure about how multiple connections degrade it, but it definitely is degraded.  As soon as something decompresses in SAB, whatever I'm watching, whether transcoding or not freezes up.  I've even tried just watching something in VLC and that freezes as soon as something is unpacking in Sab.  After the unpacking is over, the video is still frozen and I have to exit out of VLC and restart the video, but then it's fine until it happens again.

@pzt - it seems as if Plex doesn't remove transcoding data from the transcode directory and if that fills up, then I can see how it would cause problems.  It would need more intensive purge logic than just a flush though because if you only had the last few minutes as Vulcanworlds suggested, then wouldn't that eliminate the ability to effectively search/fast-forward/rewind?  Granted, that feature doesn't seem to work too keen for me right now anyways, especially if I'm streaming to a 360, but just throwing out questions.

I haven't had the free time lately that I wish I'd have to really dig into this stuff, test, and post results.  I'm also out of money to buy any other equipment to benchmark against.

Vulcanworlds, that's an interesting idea. I hadn't considered that plex would generate intermediate files in the process of transcoding; I figured it would just be a plain old stream that didn't actually land anywhere.

In that case, tmpfs is perfect. It's pretty much designed for this sort of thing, for data that is short-lived and not permanent.

One word of warning to anyone else reading that has a passing familiarity with Unix/Linux is that /tmp is no longer a RAM disk on a bunch of Linux distributions. Ubuntu (and a bunch of its derivatives) now leave /tmp on the root filesystem, which  can be a surprise. Even the server version of Ubuntu (certainly 12.04) does this these days.

I've been trying to cleanup the transcode dir with a cron task:
 

find /ramdisk/plex-transcode-* -type f \( -iname 'media-0*.ts' ! -iname "*.tmp" \) -mmin 0.33 -exec rm  {} \;
find /ramdisk/plex-transcode-* -type f \( -iname 'chunk-0*' ! -iname "*.tmp" \) -mmin 0.33 -exec rm {} \;
 
Which seems to delete the old files, but  somehow it's not a 100% stable fix

1st of all.
Sorry for necroing this thread. :frowning:

2nd.
I can not get Plex Media Server to run on a RamDisk. I am Using 32Gb Corsair Vengeance Pro 2400 DDR3 and DimmDrive.

If I run Plex Media Server, from the RamDisk, the client can not connect to the server despite all manual workarounds.

Running Plex Media Server, off of my HDD and Plex connects to my tablet without a hitch.

I figured I did not have enough to post to create another thread.

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.