Our forum migration to Discourse is underway and scheduled to last through June 21. During the migration, the forums will be read-only, except for a single temporary forum (contents of which will not be getting transferred). Read our announcement post for more information about the forum migration.
Hey folks, there is a new Podcast category for forums https://forums.plex.tv/categories/podcasts
If you have not already, we suggest setting your Plex username to something else rather than email which is displayed on your posts in forum. You can change the username at https://app.plex.tv/desktop#!/account
Welcome to our forums! Please take a few moments to read through our Community Guidelines (also conveniently linked in the header at the top of each page). There, you'll find guidelines on conduct, tips on getting the help you may be searching for, and more!

Plex Transcoder RAM Drive Experience

JesterEEJesterEE Members, Plex Pass Posts: 6 Plex Pass

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

Tagged:

Comments

  • Uh OhUh Oh Members, Plex Pass Posts: 87 Plex Pass

    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

    Server: IBM X3200 M3
    Processor: Intel Xeon Quad Core X3470 2.93 GHz
    RAM: 4GB
    OS: Windows Server 2012r2
    Storage: Hot-Swap 4TB, 4TB, 1TB

  • JesterEEJesterEE Members, Plex Pass Posts: 6 Plex Pass

    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

  • cayarscayars Members, Plex Pass Posts: 4,819 Plex Pass

    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. :)

    10.7K+ Movies, 435 Shows - 37K+ TV Episodes, 515 Christmas Movies, 480 Documentary, 335 3D Movies, 1300 Sports Events, 1280 Educational Videos, Premium Music: 215K+ Tracks, 900 GB Plex Meta-Data. 9 Network Tuners.
    Thread on my setup with some tips and tricks: https://forums.plex.tv/discussion/131308/cayars-setup-walk-through-and-some-tips-and-tricks/p1
  • Uh OhUh Oh Members, Plex Pass Posts: 87 Plex Pass

    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. :)

    Server: IBM X3200 M3
    Processor: Intel Xeon Quad Core X3470 2.93 GHz
    RAM: 4GB
    OS: Windows Server 2012r2
    Storage: Hot-Swap 4TB, 4TB, 1TB

  • JesterEEJesterEE Members, Plex Pass Posts: 6 Plex Pass
    edited March 13

    @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\to\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\to\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\to\Transcode Destination\Transcode\Sessions", BUT the transcoded media will actually be put directly into "Drive:\Path\to\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\to\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\to\Transcode Destination\Transcode\Sessions", BUT the transcoded media will actually be put directly into "Drive:\Path\to\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. :(

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

    -JesterEE

  • Uh OhUh Oh Members, Plex Pass Posts: 87 Plex Pass

    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.

    Server: IBM X3200 M3
    Processor: Intel Xeon Quad Core X3470 2.93 GHz
    RAM: 4GB
    OS: Windows Server 2012r2
    Storage: Hot-Swap 4TB, 4TB, 1TB

  • kclimiekclimie Members, Plex Pass Posts: 79 Plex Pass
    edited March 14

    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.

  • JesterEEJesterEE Members, Plex Pass Posts: 6 Plex Pass
    edited March 14

    @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

  • cayarscayars Members, Plex Pass Posts: 4,819 Plex Pass

    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

    10.7K+ Movies, 435 Shows - 37K+ TV Episodes, 515 Christmas Movies, 480 Documentary, 335 3D Movies, 1300 Sports Events, 1280 Educational Videos, Premium Music: 215K+ Tracks, 900 GB Plex Meta-Data. 9 Network Tuners.
    Thread on my setup with some tips and tricks: https://forums.plex.tv/discussion/131308/cayars-setup-walk-through-and-some-tips-and-tricks/p1
  • broncosaddictbroncosaddict Members, Plex Pass Posts: 51 Plex Pass

    @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. :(

    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.

Sign In or Register to comment.