Performance Question about Server Cache files

[Hercules20 4]

New to Emby.

Settings > Advanced > Cache path

I have RAM transcoding set up through tmpfs and I am trying to make any settings tweaks to make Emby as responsive as I can.

I see the option to change the Cache path and I am wondering if there's any sense in directing it to the same directory for RAM transcoding to make use of the RAM? 

Thanks!

[Abobader 3464]

Hello Hercules20,

** This is an auto reply **

Please wait for someone from staff support or our members to reply to you.

It's recommended to provide more info, as it explain in this thread:

Thank you.

Emby Team

[GrimReaper 4740]

If you have extra RAM, sure you can. Though if your cache is already on an SSD you won't see very considerable improvement (I keep both cache and data folders junctioned to RAMDisk, with daily dumps to SSD). If it's on a spinner, then yes, it might somewhat breathe a new life into your system. 

As for transcoding in RAM, there's not much point besides saving some wear and tear on your SSD as transcoding is usually CPU - not I/O - limited, and can even have detrimental effects, as stipulated here:

On 11/1/2021 at 6:20 PM, softworkz said:

I'm afraid, but I have to disagree on that whole subject.

With regards to using a RAM disk for transcoding-temp, I can only say: Don't ever do this! It's a very very bad idea!

You don't even need an SSD for transcoding-temp, but (important!): It should be a local disk - no NAS, no SAN or anything like that. 
For a perfect setup, you'd have an average magnetic disk - but dedicated only for that single purpose.

In a while, I'll come back and explain why.

 

On 11/1/2021 at 8:13 PM, softworkz said:

It's a complex subject and I wanted to respond to some other things first and see whether I'd be still in the mood to explain
In fact, the recent couples of posts are covering so many things that I'm not quite sure where to start. Let's go for the ramdisk part first:

First of all: Sure! We have all learned that we can improve performance of certain processing tasks by things like using SSDs instead of conventional HDs and ultimately even using RAM disks.

What are those "certain tasks" that can be accelerated by such measures?

=> IO-bound tasks, i.e. tasks where the limiting factor is IO throughput

Is this actually a problem that we're having with transcoding that we'd need to solve?

=> No - not at all. Even with the fastest hw accelerations or even when assuming one that would be infinitely fast - the source data needs to come from somewhere. It doesn't come from RAM - it comes from some disk. The output bandwidth when transcoding is usually much smaller than the input, so what comes from some disk storage (network or local) can easily be saved to another disk storage.

Are there any reasons at all, why we would want to accelerate disk IO?

Now, let's assume an odd case, like 5 transcodings of videos from 5 different source disks, with the results all landing at our single disk with the transcoding-temp folder.
Even in that case, we would need an extremely powerful hardware acceleration to saturate the transcoding-temp disk's, IO capacity. And there, we would have each of those 5 transcodings running at a multiple (e.g. 5x or even 50x) of the required transcoding speed (1x).
By default, we are running transcodings "as fast as possible". That's not really a good thing, because this will always cause to max out one of the following resources: CPU processing, system memory IO, disk IO, hwa IO or hwa processing - to its limit, even though that wouldn't be required in any way to improve the user experience. It's often a waste of resources - e.g. when a user stops watching after 5 minutes and we have already transcoded the whole video..

To deal with those things and use resources more wisely, we have introduced throttling - just the opposite of "as fast as possible", for all those cases where transcoding is running much faster than needed.

Looking at the other end: None of all those cases where transcoding is too slow, can be accelerated by using a RAM disk.

Actually, this has just the opposite effect: it can slow down your transcodings instead of accelerating.

And not just that: A ramdisk can even negatively affect Emby server operation in general.

The problem with the throttling we have is that it is binary - like a refrigerator: there's just ON or OFF switching over time. While it's on, it still runs with maximum speed. Transcoding itself requires a lot of memory IO - all this IO bandwidth will be taken away and not available for regular Emby operation.

And now you want to add a ramdisk on top of this, creating even additional memory IO for writing and reading? Very bad idea! 
The more shoulders on which we can put these things, the better - the right "shoulder" for transcoding temp is a disk. Even when the CPU does the transfer of memory in either case - it's still totally different: RAM is just not optimized for such access patterns. When you use the RAM in this way, you will permanently flush the memory caches (specifically L3) with other data, and this can in turn very badly affect sw filtering operations where the same memory needs to be accessed repeatedly.

Edit: And as mentioned, also Emby Server and all other server operations. 

In Summary

With a RAM disk, you would:

• Either not accelerate anything or at best, accelerate something that is already running much faster than needed
• Use memory IO bandwidth and CPU cycles (for memcopy)  - which are badly needed for other operations
• Negatively impact overall server operation

Full read starts here:

 

Edited March 14, 2023 by GrimReaper

[ebr 16184]

I do NOT suggest pointing your cache path to a RAMDrive.  That's going to end up costing you in performance more than likely as the entire cache will have to be re-built with a restart.

[GrimReaper 4740]

5 minutes ago, ebr said:

I do NOT suggest pointing your cache path to a RAMDrive.  That's going to end up costing you in performance more than likely as the entire cache will have to be re-built with a restart.

That depends on particular setup and programs boot sequence, wouldn't you say? I don't have custom cache path but have it symlinked - basically same net result - and it ain't rebuilt as dumped RAM image is loaded first. 

[softworkz 5068]

To summarize:

• Transcoding-Temp Path: Never use a RAM disk for it - you just make things worse
• Cache Path: Don't use a RAM disk (for the reasons @ebrmentioned) - except you have some persistence strategy in place like @GrimReaper

[Happy2Play 9781]

What size is your library.db?

Have you adjusted your database cache size?

[Hercules20 4]

Thank you all very much for your responses!

I have seen your names as I researched setting up Emby. I do appreciate the information and help.

 

I have adjusted my database cache for 5000 as I have RAM to spare. 

I've restored the transcode back to its default now that I reviewed softworkz explanation.

At this time I was using Plex, which occupied a great deal of my NVME storage. After recently experiencing a bad Plex update which corrupted a database, I've decided to just move on to Emby instead. I had my Emby server cache in regular hard drives - and to be fair - Emby was already notably more responsive than Plex ever was. I am curious if I copy over the server cache into the NVME drive whether I'll see any further responsiveness. I'll see for myself soon.