Would RAMDisk provide better performance for transcoding then HDD as I don't have an SSD on my server?

I only had an HDD and no SSD on my online dedicated server. Would I have better transcoding performance if I use RAMDisk as an SDD alternative?

that would mainly depend on if the HDD is the bottleneck when transcoding, and if you have sufficient ram to set aside for transcoding.

the main reason to use ram transcoding is not necessarily for performance, but to avoid unnecessary writes to SSD.

if you are running linux, I wouldn’t bother with ram transcoding unless you have 32gig or more ram.

I agree with @TeknoJunky.

A ram disk is most beneficial when trying to minimize SSD wear.

It may help if you have too many concurrent transcodes or if you have a slow hard drive. But in both cases in all likelihood bad performance is the result of not enough CPU power for the transcoder.

Having said that… if you still want to give it a try and derive the benefit from both worlds you can do a couple of things in linux:

  1. You can provision a ram disk that is larger thank your actual ram. Any excess data written to your ram disk which doesn’t actually fit into your ram will be written to your swap file.
    You may pay a performance penalty with this approach if you end up using more ram than available.
    or
  2. You can create two partions. One is your ram disk and the other a physical partition on your hard drive. You can then join them together into one using mhddfs.
    It is a little harder to setup. But it does have the advantage that you can allocate just a portion of your ram (a portion you know will not cause swapping even when ram use is at its highest). Any overflow would be handled by your hard drive no different than how it does it today.
    There will be a some overhead (consumed cpu) by the mhddfs.

I have 64GB RAM… that’s why I’m considering it since I do not have an SSD.

1 Like

Keep in mind that you can get now an SSD much cheaper
than sufficient RAM for several concurrently running transcodes/remuxes.

But I’m only using around 3GB out of 64GB RAM on my server and I’ll have to pay more to attach an SSD. Is it really a bad idea to use RAM? let’s say around 32GB?

1 Like

I haven’t seen many success reports. Particularly when using more than one transcoding job concurrently.

Plus, a large part of your RAM is already used by your OS as file cache to buffer those hard drive read/writes.

But you’re free to try for yourself.

I’d say go for it! If you already have the RAM then why not use it, right?

I’m using a RAM Disk as well. In my case I used it to offload some of the writes from the SSD that was being used for transcoding. Plex was doing a lot of writes to it, which is fine, that’s exactly what it was for… but I also already had quite a bit of RAM available that was not being used. So I set some of it apart into a RAM Disk and this is where the writes happen first. For most transcode sessions the amount of ram is more than enough. Sometimes there are quite a few transcodes happening at the same time or a 4K movie is being transcoded, so the overflow goes into the SSD like it used to, that way I never run out of transcode space.

It works great.

I tried both approaches I mentioned in my previous post. I like using mhddfs better (#2), but #1 is much easier to setup because you don’t have to configure anything outside of the RAM disk setup and making sure the swap file is large enough to hold the overflow.

RAM disks for the transcoding temp are really useful to save writes to the drive but they come at a cost. Any RAM you give to your RAM disk is unavailable for other purposes including disk cache.

If you look at the typical bitrates of a transcode and the throughput of a HDD, it’d take numerous transcodes to saturate a spinning disk. Additionally the disk cache (in RAM) sits between the disk and all software disk operations so this accelerates your performance so long as you have sufficient RAM to spare for the cache.

So, unless your transcode temp is on the same disk as your media and you are on the edge (such that writing to transcode temp is starving reading the media such that it can’t be read fast enough) then a RAM disk isn’t going to give you better performance. That leaves saving writes to the drive, which if you were using an SSD is really the only valid argument.

1 Like

the multiple streams is another great point.

if you have a 32 gig ram drive, and have 1 or transcoding streams going on, it is very possible that the transcode ram drive could get full enough that you will not be able to start another stream because there is not enough space for plex to start additional transcodes.

so if you did attempt ram transcoder, you should experiment with how many streams you can have running before you start running out of transcode space and plex generates a cannot play your movie error.

if I recall correctly, other threads on this topic have indicated that you should have a minimum ram transcoder large enough to support a full copy of the content you typically transcode…

ie if you are transcoding 30 gig bluray rips, you should have at least 30+ gig ram drive.

if you are attempting to transcode 4k (and you should not be) rips of 60+ gig, then you would want 60+ gig ram drives.

and if you expect to have multiple large streams going, then you will obviously want to have even more transcode ram available.

I don’t think this is a problem anymore with modern operating systems.
In both Linux (tempfs) and Windows (Block Storage Services) you can create RAM disks that are way larger than the total amount of RAM available to you. If all your RAM is saturated, all overflow is gracefully handled (at a performance penalty) by the operating system’s swap file.
You just need to make sure the swap file is at least as large as the total amount of RAM or the total Size of the RAM disk (whichever is larger).
Or, better yet,
Make use a utility like mhddfs (linux) or its equivalent in Windows (I think Block Storage Services can also do this, but I have not tried it before) to chain multiple partitions into one.
You make the first partition your RAM Disk, then your physical partition is chained as the second partition in the mhddfs volume and done. Any files that fit into the RAM disk will be written to it, any excess will be written to the physical partition. Again, if there is not enough free RAM the utility or the OS handles it so it only writes up to as much ram as there is available and the excess will go to the physical drive. In other words, if you create a tempfs (ram disk in linux) volume of 32 out of your 64 GB and chain it to another volume of 120 GB (physical partition), then to Plex this appears as a single 152GB directory.
Say that at a given point in time, your OS and whatever programs you are running are eating into your memory and consuming 52 GB of RAM. That just leaves 12 available to your 32 GB Ram Disk. It is still OK, mhddfs handles it gracefully by writing up to 12 GB into that ramdisk, the rest overflows to the physical drive.

There may be a way to block off the RAM used by the ramdisk so the above doesn’t happen (the OS eating into most of your ram). But I didn’t explore that option since I thought this was a more flexible and graceful way of handling ram usage… at least for my needs.

yeah, I should have qualified that in the case when the ram drive is static sized.

I assume you mean on the fly transcoding? Have you considered pre transcoding files as they are added

Can you please help me with that? How can I automate transcoding?

He is probably referring to the optimize function.

If you select a video and click the 3 dot menu there should be a menu for optimize where you can choose from several preset modes to create a transcoded extra version to be used when necessary in place of the original.

The original is not modified you will just have an idea xtra hidden copy that Plex wil use when needed.

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