Plex Transcoder RAM Drive Experience

General Discussions
1

I was experimenting with some RAM drive options for transcoding on my Plex server today and found some interesting take-aways through experimentation I wanted to share with the community.

  1. Plex does it’s own transcoding garbage collection mid-stream.
  2. Plex tries to keep at least 100 MB of free drive space at all times.
  3. The size of the RAM drive only needs to be big enough to support:
    • The number of simultaneous streams you want to be able to transcode
    • The amount of cached playback you want to retain during the transcoding process
      • for rewinding without restarting the transcoder process (which kills the current transcoder session and starts a new one)
  4. Performance improvement was modest-to-negligible in comparison to transcoding to a “slow” consumer grade HDD.
  5. If the stream is paused while the transcoder continues to process the media, and the RAM drive fills up, the transcoder with fail. The playback (transcoder session) will need to be restarted and all that caching will be for nothing!

How I tested

I made a 150MB NTFS RAM drive and played a x265 encoded 5Mbps video hosted on a locally JBOD pooled NTFS (separate from where Plex is installed) to a Roku client. This forced Plex to transcode the media to h264, so I can test how the transcoded stream was handled. My server is on the edge of providing smooth playback (Transcode speed ~= 1) for the particular media file so it was a good test for identifying where hiccups in the transcoding processing came. I also recreated the RAM drive a number of times with some other options (dynamic memory allocation, only allow physical memory [AWE, no pagefile]) and another size (1 GB) to see if there were any differences in the experience or file system handling. With all these options, the size of the resulting transcoded media would be larger than the RAM drive.

I first tried to stream the media live (as fast and as the transcoder would give it to me) and observed the filesystem and transcoded stream pieces (.ts files) as they appeared on the RAM drive. I found that Plex would keep as many pieces in the session as possible before removing the oldest viewed pieces to make room for for the new pieces. This garbage collection process seemed to kick in when there was ~100MB left of free space left on the drive. At this point, Plex reclaimed a fair amount of memory all at once (~300MB) of early stream pieces. It then filled this space up again until there was 100 MB free and did the same.

Next, I started the transcoding session and waited for the RAM drive to get ~95% full before starting playback. Even though space was getting close to full, Plex seemed smart enough to know that the first few pieces of the stream were not yet consumed, so it didn’t delete them. Once started, the experience was close to the first test were Plex kept as many old pieces of the stream around as it could while continuing the transcode.

In both these cases, memory needed to be reclaimed by Plex to continue the stream. I noticed that this reclamation was also somewhat smart so I wanted to look at it a bit more.

Using a larger RAM drive (1 GB) I started playback and about 20 minutes in I paused the stream. This was long enough such that the earlier pieces of the media needed to be removed while live streaming to make room for the next pieces, but since my server wasn’t very good at streaming the media, what I was watching right before pausing was the newest piece of the transcode. So I could have rewinded a bit and still had the pieces in the cache, but I didn’t to see what happened with the garbage collection process. I noted that again when the free space got to 100MB, Plex did it’s garbage collection and reclaimed a large chunk of memory as expected. I waited and noted that as the space filled back up to the 100MB of free space, Plex started reclaiming smaller pieces; ~15-30 MB at a time. Seemingly, Plex is trying to balance how much memory it reclaims with how much rewinding space it leaves for the user. It continued to take these smaller chunks until the transcode caught up to the current playback position and continued to fill the drive keeping the oldest piece to continue the playback.

I continued watching the free memory on the drive with the media paused. When the RAM drive was completely filled to 100% usage, the transcoder again seemed to recognize the earlier pieces were still needed so it didn’t delete them, but instead, it killed the whole session providing the error. “Conversion failed. The transcoder crashed or failed to start up.”. I’d like to think this is an edge case and that a better option for the transcoder would be to go into an idle mode waiting till there were consumed pieces before continuing. Maybe a dev sees this study and adds a ticket for a patch. Maybe not. Know this is a limitation to transcoding with a small-ish destination drive.

In all test cases, the transcode was CPU limited in my circa 2007 server. I have been transcoding to a spare WD Green drive (5400 RPM) to save SSD wear on the system drive. Also, all the metadata in my Plex library makes it too large for my system SSD, but I probably wouldn’t house it there anyway. After over 3 years of Plexing this way, it hasn’t been an issue, but I was curious if I gained any performance with the RAM drive. Apparently, I did … all 0.2-0.3x of it. Pretty negligible … possibly in the noise of a streaming experience, but I’ll take it. If you’re transcoding to an SSD (which is reasonable, I don’t want to start that flame war here), you likely won’t see any improvement.

Testing with both static and dynamic memory allocation for the drive yielded the same results as far as transcode speed performance. Though, there was not much else going in the server at the time … so it’s feasible that the memory was almost sequential in dynamic mode anyway. So unless you just want to have a known amount of memory for Plex right off the top … there was not much reason to use static allocation.

Other

The one thing that is notable that I haven’t seen anywhere else, due to Plex trying to be smart, if you opt to use a RAM drive for the transcoder (or any small drive really), things like Plex-Free-Mem and PlexTidy are not required. There’s no reason to auto-manually do what the software does for itself.

I can not speak to multiple streams because I didn’t test that case. I imagine that the magic free space number is 100 MB to allow a few streams some leeway to do garbage collection individually and not completely fill the drive prematurely. This is pure speculation though on my part.

Conclusion

IMO, even though this is really easy to set up, if you’re using a HDD, this is likely more trouble than it’s worth. Speed gains are modest, and the caching constraints I noted can make the experience less than stable. If your using an SSD and are worried about excessive wear, or are physically limited (# SATA ports, power load, etc.), this is an option without introducing another piece of hardware to the system.

Though, I think the best solution is probably to just get a really small SSD that you don’t care about and use that.

I hope this was helpful to someone!

OS: Windows Server 2012 R2
Plex Server: 1.12.0.4829
RAM Drive: ImDisk

-JesterEE

9 Likes
2

I’ve been looking at adding a RAM drive, as my OS drive is taking the beating right now. Still don’t have the money yet…

If I remember right, I think your RAM drive size is far too small. I believe the quote was 4GB per active movie you are transcoding. That’s quite a bit, especially for a 2007 model year system. Maybe you could do 2GB if you don’t have simultaneous transcoding sessions going at the same time. Either way, the reduction of wear & tear on your drives could be worth it. I’ve got on average 2 transcodes going on at the same time. I’d likely need 8+GB of drive space, as one of my users pauses their streams quite often. Good to know that the transcoder process will fill the entire dedicated drive space during a paused session.

You can see the recommendations given in my prior thread here: http://forums.plex.tv/discussion/293541/use-a-ram-drive-for-transcoding-cache-how-big-should-the-ramdrive-be#latest

1 Like
3

This was not about what size to make the RAM drive but more about what happens when it’s used. Specifically what happens when it’s too small, because most people will run into that situation regardless of what size they make it. A lot of forum and Reddit posts debate drive sizing but I haven’t seen anyone really look at the limitations.

IMO that conversation is also not helpful because it’s all opinion based. RAM drives for transcoding is a 2-3 year old topic and I was really surprised that I did not see any posts about people doing edge testing on thier setups. This is that post.

Anyone can say your typical media transcode is going to result in a file that’s X big, and you expect to have Y simultaneous streams, and you want C overhead, so you obviously need a X*Y+C sized destination drive at minimum. But once you start plugging in some realistic numbers you quickly find unless you:

  1. have really low quality media to serve
  2. only serve one or two streams at a time
    or
  3. have commercial grade equipment

you’re likely not going to have enough RAM to satisfy the demand.

After finishing my analysis I decided to use a 3 GB dynamically allocated drive. This has more to do with the load/limitations of my server (it does a lot more than Plex) and less about the Plex usage or quality of my media. I probably should be running at least a 10 GB - 12 GB drive, but that’s more than my old machine even has. I’m doing this as a trial to see if it meets my needs and I think people that are interested in RAM drives will have to do a decent amount of testing on thier own because everyones situation is different.

-JesterEE

1 Like
4

I tried this with a 32 GB Ram disk and didn’t think it was worth doing. Maybe if you are on the fringe of IO on a HDD or SSD but you won’t really get a performance gain if the system doesn’t already have a roadblock in place.

This could save wear and tear on an SSD so for that purpose it could be useful I suppose. However, I think it would be wise to test syncing and other features that could make use of the transcode directory before committing to this just to make sure you don’t cause yourself grief.

Personally I can think of better things to use the RAM for. :slight_smile:

1 Like
5

My only reason to do this is to save wear and tear on the drives. I/O is secondary to that. The mere fact that I’ve not yet landed enough saved up money to boost me over 4GB RAM, should make it pretty evident that replacing a hard drive would be even more problematic. :slight_smile:

1 Like
6

@cayars, OK. Reasonable stuff. I checked out how Plex does Sync and Optimize operations on the server side using the RAM Drive. And I was quite surprised!!!

Apparently, Plex does not use the transcode destination for either the Sync or Optimize functions! Even when media needs transcoding, it creates a session on the “Transcode\Sessions” directory on the transcode drive but doesn’t use it!

More details

First lets take a look at what the directory structure looks like for the Plex Media Server files (not the installed software, but rather the files that make the glue between you media and the software and the metadata that is generated) as it pertains to transcoding functionality. Before moving the transcode destination to the RAM drive, this is what it looks like:

  • Drive:\Path o\Plex Media Server
    • Cache
      • Photo Transcoder
      • Transcode
        • Sessions
        • Sync+
    • Everything else

When you make a separate transcode destination, you would think that It would move the whole “Plex Media Server\Cache” directory … or maybe the “Plex Media Server\Cache\Transcode” directory … that would make a lot of sense because all that stuff is cached for the active server process.

! actually the “Photo Transcoder” directory is persistent, as well as some loose files in the “Cache” directory … so that wouldn’t really make sense to have in a volatile transcode destination.

But, what Plex actually, does is it moves the location of just the “Plex Media Server\Cache\Transcode\Sessions” directory.

So your transcode destination looks like:

  • Drive:\Path o\Transcode Destination\Transcode\Sessions

OK, so why is this important? Well, every time you start a transcode, it makes a new session for the transcoder by making a temporary subdirectory under the “Sessions” directory to house the files from PlexTranscoder (ffmpeg). BUT, while this directory gets created for stream, sync, and optimization transcodes, the only one that actually uses it is the stream transcodes!

When you Sync from another device, Plex will create a session in the “Drive:\Path o\Transcode Destination\Transcode\Sessions”, BUT the transcoded media will actually be put directly into “Drive:\Path o\Plex Media Server\Cache\Transcode\Sync+”. Instead of being created in chunks like a streamed transcode (lots of .ts files), Plex will just make a single media file (.mp4) and a subtitles file (.srt) if appropriate. When complete, the temporary (empty) transcode session directory is deleted. So, this operation almost completely sidesteps the transcode options in the software predominately using wherever you have your “Drive:\Path o\Plex Media Server”.

When you Optimize, you tell Plex where to put that media; either “In folders with original items”, or in the media root directory (e.g. Drive:\Media). When optimizing, Plex will again create a session in the “Drive:\Path o\Transcode Destination\Transcode\Sessions”, BUT the transcoded media will actually be put directly into “Drive:\Path o\Media Destination Selection”. Instead of being created in chunks like a streamed transcode (lots of .ts files), Plex will just make a single file media (.mp4) and a subtitles file (.srt) if appropriate. Actually, the subtitle file is housed in the transcode session subdirectory temporarily, but not the media file being created. So, this operation too almost completely sidesteps the transcode options in the software predominately using wherever you have your “Drive:\Media”.

What’s interesting, in both scenarios, Plex goes through the effort to put an extension on the media file before it’s done transcoding to signify that it’s not done yet … but it doesn’t use the transcode location to house it.

Results

Plex will thrash your HDD, wear you SDD, and/or cause your real-time RAID/JBOD redundancy storage to go nuts for a time if you use either of these functions … whether you like it or not. No way around it. :frowning:

I’m not a software developer by trade … but I dabble. And this … this, IMHO, is bad design. Plex please … please fix!

-JesterEE

4 Likes
7

Good to know about optimize and sync. Thankful nobody uses that on my server. Might as well disable it for my users just in case.

8

For me, PMS is running on an Ubuntu VM that that is stored on an NFS mount point on a Synology NAS, so I only get about 110 MB/s in testing with dd. Using the RAM drive, I get 753 MB/s. I believe that in my case using the RAM drive has significantly improved transcoding performance.

9

@kclimie No doubt a RAM drive will have faster IO than a HDD/SSD. Especially when adding the VM abstraction layer, IEEE 802 network spec, and multiple hops for each file you Plex (NAS → router → Plex VM → router → Plex client).

Let’s talk about your quoted numbers. Are you by chance on wired gigabit LAN? If so, 1Gbps = 125 MBps … so your NAS IO to your server is running at 88% of the theoretical maximum bandwidth … that’s pretty good IMO. Your RAM performance, that’s another story … your quoted speed is really, really slow! A SATA III connection is 6Gbps = 750 MBps. So your saying your RAM drive is maxing out at SATA III speeds? I hope not for you!

Quoting the Wikipedia

For example, a computer with dual-channel memory and one DDR2-800 module per channel running at 400 MHz would have a theoretical maximum memory bandwidth of:

400,000,000 clocks per second × 2 lines per clock × 64 bits per line × 2 interfaces =
102,400,000,000 (102.4 billion) bits per second (in bytes, 12,800 MB/s or 12.8 GB/s)

And that’s for 2003 tech! Surely this number is an error … guaranteed. dd is likely limited on that computer; possibly Linux kernel support, maybe something else (like a command line/program setting), but it looks like for RAM speed testing you shouldn’t use it till you figure out what’s up.

Regardless, looking at the “benefits” of your RAM drive can’t really be quantified by throughput. Sure, it’s nice to say “it goes super fast”, but you really don’t need it to … honestly, you don’t. If you consider the UltraHD Bluray spec. says that the maximum capacity of a triple layer disc with the high transfer rate option is 100 GB at 144 Mbps (18 MBps). And that’s probably the highest quality consumer grade media source available today. So, if you are using a wired LAN, and your Plex client supports the media natively, even your NAS IO is more than fast enough to do the job … 6 times over. Even an 802.11n connection could probably do this if the point-to-point line of sight was unobstructed.

What is more interesting to look at for RAM drives in Plex is the speed at which Plex transcodes and serves the video to the client. This is CPU limited (or GPU limited if you use it). That’s a fact. Using a RAM drive won’t change that. To view that information, sometimes the client (like the Roku) reports the transcode speed, other times it doesn’t and you have to look through the Plex server logs to find it. Either way, I encourage you to do those tests on your system and report back! The more useful info the better!

-JesterEE

1 Like
10

Not to mention Plex will throttle the speed of the transcoding anyway to just stay enough a head of the client as needed. Usually no overall gain to be had for normal circumstances unless you already have an IO issue.

If you for example are running you OS, swap drive, Plex as well as all of your meta data on a 5400 RPM drive (typical default install) then you may have an IO issue where a RAM drive would help. But first I’d switch that drive to SSD and/or spread things out to different drives to eliminate the IO issue.

Carlo

11

@JesterEE said:

Results

Plex will thrash your HDD, wear you SDD, and/or cause your real-time RAID/JBOD redundancy storage to go nuts for a time if you use either of these functions … whether you like it or not. No way around it. :frowning:

I’m not a software developer by trade … but I dabble. And this … this, IMHO, is bad design. Plex please … please fix!

-JesterEE

I raised this issue almost a year ago if not longer and got absolutely nowhere…I don’t think I received a response of any kind. Realize they can’t and don’t respond to all the posts, but the fact they are still doing it tells me they will not change it.
It was causing me so many problems with drivepool duplication and network congestion that I had to stop. I use it from time to time for a film here and there, but I can’t just turn it on to do everything or everything current.

I agree with you on the poor design. This is a very, very bad design issue, I have no idea what they were smoking when they designed that piece as it makes zero sense…not even an option to use the “normal” transcoding location.

12

I’ve got a large pool of storage running for my plex, 8x3tb WD reds for tv, 5x8tb wd reds for movies and a drobo nas for deprecated tv shows. I was running plex db off a cheap 480gb ssd and ran transcode on the same drive. I allow up to 10 transcodes off this hardware and have a gpu and server os booting the hardware.

I found after 2+ years of running in this configuration that the ssd storing my 1.5Million file metadata folder set and transcodes was already at 17tb of wear and was getting odd IO failures in system logs for the drive.

In a panic I ordered a new M.2 WD black nvme and plopped my plex DB onto this but pondered a new solution for transcoding and setup a ram drive on the system with 10gb of the 32gb total from the machine for this purpose.

After some initial testing and realizing I couldn’t easily setup the disk to come back on bootup without some additional scripting I found a free app: imdisk toolkit that does this and have had zero issues since setting it up.

My system can handle around 10 transcodes without running into issues though I typically run between 2-4 at a time max most days. This solution so far has been stellar, as I’m not concerned about storing any of the data on this disk between reboots it’s an absolute dream and saves me the worry of burning out the nand on a new m.2 nvme disk.

I believe 10gb for this purpose will be adequate and haven’t heard any complaints from users of the system. If you’ve got the spare memory to afford it I highly recommend this solution versus wearing out your expensive nand or spinning media.

2 Likes
13

Well I just disabled my 16Gb ram drive (machine has 64Gb+32Gb) since it was causing DVR failures for running out of disk space. Not something I found in anyone elses reported problems. I was thinking of upping it to 32Gb (which was the original plan) but figured even that might not be enough ‘space’. So opted instead to recycle an old 128Gb Evo Pro 850 SSD into the equation. keeps the wear/tear off the mirrored 256Gb SSDs for Plex db/cache itself. Plex was running 3-4 DVR recordings when it failed due to space, possibly one stream playing to our NVidea stream. but my understanding was it would deal with limited space nicely and that is sure not my experience so far. Just nuked a nights worth of recordings with space failures. Good thing I have YouTubeDl setup as a backup downloader of shows for plex especially with all the other funky no recording situations I am still trying to figure out.

So what is needed in terms of space for 5-6 recordings and 2-3 streams transcoding? 32G? 64G?

14

I’ve never seen the ramdisk be utilized for recording tv, I’ll have to check the next time I’m recording something, I presumed it stored the data for that video in the folder it’s recording to. I suppose the commercial chopper might use some of that space, but I’ve never had issues with my setup running on 10gb of ram.

15

I didn’t think it was used either and 16G should handle alot of information, so needless to say I will be watching tonight to see how the 128G SSD is doing space wise!!! My understanding is the recording from HDHomeRun Duos is just a straight copy down to disk of the .TS format files so not transcoding I thought.

16

on my nas (readynas 528x/debian) I have 16 gig ram and PMS running on it.

I configured the transcode folder to /dev/shm and have not had any problems with it, and I am using hdhr and plex dvr.

/dev/shm is a tmpfs and uses RAM as a temporary filesystem (similar but different than a ram drive). Google /dev/shm and tmpfs if you want to know more.

Out of the 16 ram, with plex and other services running I am typically around 3-5 gigs used, ~10 gig cached.

When plex dvr is running, memory use averages 5 to 8 gigs or so.

I have not see any out of memory issues thus far.

This keeps transcoding files off my disk array, both for IO speed and avoiding fragmentation.

edit;
I also have an attached old ssd drive that I used to use as plex transcoder, but now used as intermediate storage for nzbget.

once configured appropriately, nzbget downloads and writes to the SSD, until the d/l is completed and extracted, then moves it to the applicable destination path.

the same would apply to torrents as well, which can be even worse for IO and fragmentation.

all of this reduces the IO load on the main drive array.

17

Well my server is Windows 2012 R2 Server lots of disk/ram, but I just checked the 128G SSD - 6924 files for almost 19G and still growing - recording three shows and it’s show three growing batches of media-######.ts files. Recording from 3 HDHomeRun Duos. Overkill yes - but it ensured we had no conflicts and will even survive ok if one dies off while I replace it etc.

BUT very strange since I did not think recording did any transcoding - and as far as I know I have not changed any settings in the system to make it transcode.

18

for plex dvr, transcoding may not be the most accurate term.

plex reads the stream from the tuner in full bandwidth mpeg2 transport stream, the transcoder appears to divide the stream up into many chunks and combine them after the show ends, and if enabled, at some point in the post-process will run comskip on the show to remove commercials.

the cpu load while recording is not super high, however the IO load is (lots of fast incoming chunks that need writing).

the post-processing comskip is fairly cpu and IO intensive.

so it entirely depends on your system and how it responds to different levels and combinations of CPU and/or IO loads.

on a custom server, it is easier to keep separate the DB and metadata, and the your actual media files, from the transcode folder.

sqlite3 db is very latency sensitive both to read/write, SSD’s are great here.
the metadata file system, isn’t necessarily a lot of writes, but a lot of scattered small files and folders being read
the transcode folder has a lot of small temporary writes and reads

Like on a nas when you have all 3 of these types of IO’s going at the same time on the same disk (or disks in the case of raid), on top of any other non-plex IO, that starts to become a major bottleneck.

what is important to understand that reading and writing lots small files is generally much slower than reading or writing bigger files.

and other than the storage of actual media files, everything about plex involves a lot of small file IO, and the larger the library the more greater the IO demand gets.

additionally, the more full your volume is, the slower it will get too.

all this adds up to, big libraries can use a lot of IO, and latency is more important than raw throughput.

Ideally to improve IO starved devices, I would have plex db/metadata on a large SSD, transcode into ram/tmpfs, and content stored on a local (not remote) semi-fast raid volume.

this spreads out the IO load to multiple physical layers.

1 Like
19

This is pretty close to optimal setup already - just the required size of the ramdrive shocked me. We have a raid 6 (using LSI 9285cv-8e, but wired to internal) of 7 3Tb 5900 rpm nas drives. mirror of Windows Server 2012 R2 on 2 500G ssds, mirror of Plex on 2 256G SSDs, transcode on a 128G SSD (instead of the 16G ramdrive I was using). A full 1 hour show is 8G in full HD so with 3-4-5 recording it can easily blow past even the 32G ramdrive I was planning.

20

For those looking at DVR streaming, please watch (and verify) where the .TS files are being written on the system when recording. Understanding how the transcoder works, I’d bet it’s putting them in the transcoding location (like streaming a media file that needs to be transcoded), but I’d like some verification on the thread for posterity.

As far as RAM drive sizing, I think everyone here is echoing the same result … for quality media, you need a lot of RAM. No surprise. @drewsaurs experience is particularly interesting and cautionary. Thanks for sharing!

I have since upgraded my rigs processing power, but since my plexdb is still on the slow HDD, and it still “keeps up”, I opted to stop using the RAM drive. I ran into a few cases with very large 4K x265 transcodes where I ran out of RAM when pausing the stream, and I ran out if patience with it :smile:.

Also noteworthy, the database backup option is great for safeguarding yourself from transcodes killing the source drive (thus nuking the database too). Too bad Plex doesn’t insist you set the backup location to another physical drive on install for people that don’t know how volatile this thing really can be :roll_eyes:.

-JesterEE