I've recently discovered that using /mnt/cache/appdata/folder directly in a Docker container that would otherwise use a cache-preferred share (such as /mnt/user/appdata/folder) is MUCH faster for DB-heavy applications, as well as general R/W performance, and wanted to see if this performance drop was expected, or something that could be improved in UnRAID.

 

My first tests were with Radarr, where in the debug logs I can see that when I load the full library via API (on an app on my phone), the request takes around 3000ms when Radarr is pointing to /mnt/cache and 30000ms when it is pointing to /mnt/user. 10x slower!

 

Also, doing some dd write tests show that writing directly to /mnt/cache/appdata I get around 1.8GBps write speeds, while when writing the same file to the same location (a cache-preferred share) via /mnt/user/appdata I only get around 525MBps write speeds, so more than 3x slower. I confirmed the writes are indeed going to the cache pool when writing to /mnt/user/appdata by looking for them through /mnt/cache/appdata.

 

I guess I had assumed that since the reads and writes were going to the same location (the SSD cache pool) the performance would be roughly the same, with a small performance hit for the virtual file system, but it seems it is pretty significant. I would prefer to use this applications while having them point to the array to avoid full-disk related issues, but the performance hit is too big in my own opinion.

 

Is this performance impact expected for going through the virtual file system, or is something else going on? I don't see any logs related to R/W other than the Docker applications complaining about slow DB access when I point them at /mnt/user/appdata.

 

My stats:

UnRAID 6.12.8

Array is a mix of 2-4TB drives, all in XFS and connected via SAS

Cache pool is 2x 500GB SSDs in RAID1 using btrfs connected via SATA

Going through the User Share sub-system is known to have a non-trivial impact when performance matters.

 

if the ‘appdata’ share is all on the cache, then you can remove the secondary storage setting, and then make sure Exclusive shares are activated under Global Share settings.   With this combination going via /mnt/user/appdata will have the same performance as going via /mnt/cache/appdata.

10 minutes ago, itimpi said:

Going through the User Share sub-system is known to have a non-trivial impact when performance matters.

 

if the ‘appdata’ share is all on the cache, then you can remove the secondary storage setting, and then make sure Exclusive shares are activated under Global Share settings.   With this combination going via /mnt/user/appdata will have the same performance as going via /mnt/cache/appdata.

Thank you for the quick reply, I was actually just exploring the exclusive shares feature, which is not something I had looked into before. I do think that is probably the best solution, along with probably increasing the minimum free space for some of the other frequently-used shares that can use the cache drive, like downloads, to make sure the cache drive doesn't fill up entirely.

4 minutes ago, IceNine451 said:

to make sure the cache drive doesn't fill up entirely.

There is a Minimum Free Space setting for each pool you can set,

Just now, itimpi said:

There is a Minimum Free Space setting for each pool you can set,

I do have it set now, but it is likely just too small. I have been using UnRAID since whatever version it was at in 2012 when I built this server, and it has evolved an amazing amount over the years. I should probably give the settings a once-over to match my current uses. 😂