cache_dirs - an attempt to keep directory entries in RAM to prevent disk spin-up


Recommended Posts

  • 2 weeks later...
  • 1 month later...
3 hours ago, gacpac said:

Does anyone know the fix for the increase in CPU?

I have had Cache Dirs running for months and months without issue (always on the latest version, whatever that is). 

 

However, there was a time when it used a lot of CPU after a particular update.  I played with the cache pressure, excluded folders and adaptive level settings. Since then, Cache Dirs no longer shows up anywhere near the top of CPU processes.

 

Below are my current settings, but, the optimal settings in your case may be different depending on different factors.

 

I have excluded appdata, isos, system, domains, backup folders, etc.  There is no reason these need be cached for my use.

 

image.png.a401c5837f18f9d318b28c88bfd0dcca.png

Link to comment
I have had Cache Dirs running for months and months without issue (always on the latest version, whatever that is). 
 
However, there was a time when it used a lot of CPU after a particular update.  I played with the cache pressure, excluded folders and adaptive level settings. Since then, Cache Dirs no longer shows up anywhere near the top of CPU processes.
 
Below are my current settings, but, the optimal settings in your case may be different depending on different factors.
 
I have excluded appdata, isos, system, domains, backup folders, etc.  There is no reason these need be cached for my use.
 
image.png.a401c5837f18f9d318b28c88bfd0dcca.png
Cool! Let me try it out. I think my settings are somewhat similar. I have Time machine so I'm going to exclude that as well.

Sent from my Pixel 2 XL using Tapatalk

Link to comment
  • 3 months later...

I'm also having the same CPU spiking issues. Been struggling with this thing for months and am at the point where I'm about to just disable it.

 

My settings basically look the same as those above (although I can't see any timeout settings).

 

Do most people have this set to use separate processes per disk? Disabling that is the only thing that has had much impact on the CPU usage.


EDIT: Just FYI the high CPU usage isn't constant but it spikes to 100% like every 3 seconds for less than a second. I have a relatively good processor as well (at least for a server).

Edited by sunbear
Link to comment
  • 5 weeks later...

Hey yo all,

 

I'm the last active maintainer of the plugin cache-dir script (I guess since Joe wrote it). There's 'complaints' for a long time here, that cache-dir spikes CPU, and I finally had a look at it.

As Hoopster (partially) writes above, a solution to the CPU spikes is to turn of the /mnt/user scanning.

 

There were some hints in the cache-dir log as to what part of cache-dirs caused the cpu-issue, though as I'm the writer of those logs, its easier for me to understand them :)


Here's a bit of info about the logs. This is a sample with user-dirs being scanned (/mnt/user):
```
2021.01.31 03:01:24 Executed find in (76s) (disks 2s + user 74s) 76.41s, wavg=66.78s NonIdleTooSlow__  depth 9999 

2021.01.31 03:22:42 Executed find in (75s) (disks 2s + user 72s) 75.25s, wavg=62.39s NonIdleTooSlow__  depth 9999 slept 10s Disks idle before/after scan 6s/26s Scan completed/timedOut counter cnt=4/0/2 mode=4 scan_tmo=150s maxCur=9999 maxWeek=9999

isMaxDepthComputed=1 CPU=58%, filecount[9999]=1048758
2021.01.31 03:23:58 Executed find in (75s) (disks 2s + user 72s) 75.36s, wavg=63.44s Idle____________  depth 9999 slept 10s Disks idle before/after scan 26s/101s Scan completed/timedOut counter cnt=5/1/0 mode=4 scan_tmo=150s maxCur=9999 maxWeek=9999 isMaxDepthComputed=1 CPU=58%, filecount[9999]=1048758
2021.01.31 03:25:23 Executed find in (74s) (disks 2s + user 72s) 74.99s, wavg=64.42s Idle____________  depth 9999 slept 10s Disks idle before/after scan 111s/186s Scan completed/timedOut counter cnt=6/2/0 mode=4 scan_tmo=149s maxCur=9999 maxWeek=9999 isMaxDepthComputed=1 CPU=55%, filecount[9999]=1048758
2021.01.31 03:26:48 Executed find in (75s) (disks 2s + user 72s) 75.29s, wavg=65.39s Idle____________  depth 9999 slept 10s Disks idle before/after scan 196s/271s Scan completed/timedOut counter cnt=7/3/0 mode=4 scan_tmo=149s maxCur=9999 maxWeek=9999 isMaxDepthComputed=1 CPU=55%, filecount[9999]=1048758
2021.01.31 03:28:13 Executed find in (79s) (disks 2s + user 77s) 79.42s, wavg=65.39s NonIdleTooSlow__  depth 9999 slept 10s Disks idle before/after scan 281s/31s Scan completed/timedOut counter cnt=8/0/1 
```

It says in the last line it took 2sec to scan the /mnt/disk* and /mnt/cache*, and 'only' 77 seconds to scan /mnt/user. 77s is so much, its doing some CPU or disk access. 2 sec to scan disks indicates they are properly cached in memory. The second last line reads `idle before/after scan 196s/271s`, which indicates disks where idle before during and after scan, so no file was actually read. Hence cache-dirs is doing some crazy cpu in scanning /mnt/user

All cache-dirs does is scan with 'find', /mnt/user so there's no way to fix this, except turn it off. The reason we might want to turn it on, is that in a recent version of unRaid (some years back) it started spinning up disks if /mnt/user wasn't included in the cache. 

So in other words, its likely cache-dirs is broken now. We need to turn off /mnt/user scan, or it eats our CPU.
But if we turn it of, it might not prevent disk spin-ups, from just reading dirs. Which was almost the hole point of it.
If it still spins up disks, it might still be useful in some scenarous like if syncing directory structure regurlarly, and then the sync program doesn't have to load all folders from disk, because they actualy are in memory, unRaid just spins up the disks anyway.

Best Alex

  • Thanks 3
Link to comment
5 hours ago, Alex R. Berg said:

So in other words, its likely cache-dirs is broken now. We need to turn off /mnt/user scan, or it eats our CPU.
But if we turn it of, it might not prevent disk spin-ups, from just reading dirs. Which was almost the hole point of it.

If I understand you correctly, cache-dirs should no longer be used? Is there any use case left?

If not, I think @Squid should probably do his thing with CA and FCP.

5 hours ago, Alex R. Berg said:

I'm the last active maintainer of the plugin cache-dir script (I guess since Joe wrote it). There's 'complaints' for a long time here, that cache-dir spikes CPU, and I finally had a look at it.

Are you officially declaring cache-dirs dead for now?

  • Like 1
Link to comment
11 hours ago, Alex R. Berg said:

I'm the last active maintainer of the plugin cache-dir script ...

 

 

@Alex R. Bergyou have a sincere "thank you" from me.

 

just 2 questions for anyone invloved:

  1. The thing is, I think cache_dirs is very important (at least to me). If you have many disks you have to wait a long time for a listing. What do people who do not use it do? Is there an alternative?
  2. Why does Joe not still maintain it? Is there an "official" reason i have missed?
Edited by papnikol
minor corrections
  • Like 1
Link to comment
1 hour ago, papnikol said:

Why does Joe not still maintain it? Is there an "official" reason i have missed?

 

The 'Joe' is actually  @Joe L..  He was very active in supporting Unraid for many years but he has been largely inactive since his last post in about 2016.  In that post, he stated that he had been using 'sed' for forty years.  I suspect that he is now retired and hopefully enjoying life!  He was a real craftsman in the writing of shell scripts!!!

 

Link to comment
11 hours ago, Frank1940 said:

 

The 'Joe' is actually  @Joe L..  He was very active in supporting Unraid for many years but he has been largely inactive since his last post in about 2016.  In that post, he stated that he had been using 'sed' for forty years.  I suspect that he is now retired and hopefully enjoying life!  He was a real craftsman in the writing of shell scripts!!!

 

 

I actually remember @Joe L., I had one or two very pleasurable interactions with him.

 

I both hope that he is having a good time and also that @Alex R. Berg keeps maintaining cache_dirs

Link to comment

after the nice explenation from @Alex R. Berg i took a test here again and turned cache dirs on again while turning off /mnt/user as its useless anyway when i understand him correctly (in the current state).

 

what i can say now, its still working here at least, sample procedure i always can reproduce

 

scenario 1

all activity always ONLY on cache drive

i cut and remux  my records to mkv and save them, then scripted way is to remove original files, let filebot do its job and rename and move to proper target location, now scripted is triggering api calls to plex and emby to refresh and import the new files there too immediately and here is now the change

 

no cache dirs active -> disks spin up ...

cache dirs activated -> all good here ;)

 

scenario 2

Kodi on my Desktop Computer, opening kodi (using emby backend) also would always spinup the disks

cache dirs activated -> all good here ;)

 

prolly more but these are 2 scenarios as "daily drivers" where i can say there still is a difference with/without cache dirs.

 

cache Dir Settings

image.thumb.png.8325ccf58720546578fb592598bde810.png

 

with my Shares

image.thumb.png.97f6564122367ff4f58ee00c291457b4.png

 

forgot, im on 6.9 rc2, and since latest releases i had alot of spinups over and over again, now back to normal usage again, so thanks for keeping this alive as good as possible @Alex R. Berg

Edited by alturismo
added version
Link to comment

Hi yo all,

 

On 2/4/2021 at 8:47 PM, papnikol said:

 

@Alex R. Bergyou have a sincere "thank you" from me.

 

just 2 questions for anyone invloved:

  1. The thing is, I think cache_dirs is very important (at least to me). If you have many disks you have to wait a long time for a listing. What do people who do not use it do? Is there an alternative?
  2. Why does Joe not still maintain it? Is there an "official" reason i have missed?


I appreciate the thanks, you are welcome.

I've done some more testing myself, and I have not seen any spin-ups. So also think it is working now, without scanning of user. It's really good to get rid of that as it was CPU intensive.

Its relatively easy to test, by checking disk status in unRaids' Main dashbard. I can click the dots to spin disks down, and see if they are spun up. I then find folder on eg. disk3 and access it though user-share and see if it spins up. So far I have not reproduced any spin-ups on unRaid 6.8.3. So I think we are good, since it also sounds like it works for you out there.

Regarding maintenance, life moves on for all of us. I'm not really maintaining it anymore, but fortunately it does not need any maintenance. I might fix it though if a problem occurs that I can fix.

==== Custom Mover Script ===
Regarding @papnikol Q1, what I do if I have many disks? Well actually regardless of cache_dirs, I use my own custom mover before the official mover script. My custom mover moves certain folders to certain disks. That way I can keep all my most used files on disk1. I have 'ton' of files that consumes little space by todays standard, whereas mostly movies and backups consume huge chunks. So I just keep all those important things on disk1 and configured unRaid to never spin down disk1. It works far better for me than UnRaids default strategy. If my script hasn't chosen the location for a folder, it will be moved by the official mover. I only move to my allocated disks by custom mover when there's at least 50 GB available, and fall back to default strategy, moving to other disks. When space becomes available, my script moves it to correct disk later. All without me having to do anything besides the initial allocation of which folder goes where. If I want to move a share from one disk to another, I typically also just add a rule, and let it sort it out in the background automatically 

My custom mover also reduces risk of loss, if I lose two disks in unRaid. Because if a git repository/program is spread across many disks, I'll probably lose it all if one of the disks data is lost. UnRaid GUI cannot do that, while still falling back to using any disks, when I go full.



 

 

custom_mover move_if_idle mover_all

Edited by Alex R. Berg
Link to comment
  • 2 weeks later...
On 9/18/2020 at 6:02 PM, Hoopster said:

I have excluded appdata, isos, system, domains, backup folders, etc.  There is no reason these need be cached for my use.

 

Pardon the stupid question but isn't that everything that matters though? I thought those are the main Unraid folders that you'd want it to run on. What is it for if not that?

Link to comment
1 hour ago, frakman1 said:

Pardon the stupid question but isn't that everything that matters though? I thought those are the main Unraid folders that you'd want it to run on. What is it for if not that?

I have a similar thought - as well as considering "/mnt/user" to be an important folder to be able to cache

Link to comment
2 hours ago, frakman1 said:

 

Pardon the stupid question but isn't that everything that matters though? I thought those are the main Unraid folders that you'd want it to run on. What is it for if not that?

Things like movies, photos, videos, documents, etc. (the user shares) are what I care about having cached (via disk caching).  It is browsing those folders that can cause disk spin up I wish to avoid.

 

appdata can have hundreds of thousands of files (Plex database) and isos, domains, system and backup folders are likely to have very few so I don't really need to worry about caching them much.  Besides, other than backup folders, they are all on the cache drive which is an SSD and I don't have to worry about spin up.

  • Like 1
Link to comment
On 3/2/2021 at 5:17 AM, Hoopster said:

Things like movies, photos, videos, documents, etc. (the user shares) are what I care about having cached (via disk caching).  It is browsing those folders that can cause disk spin up I wish to avoid.

 

appdata can have hundreds of thousands of files (Plex database) and isos, domains, system and backup folders are likely to have very few so I don't really need to worry about caching them much.  Besides, other than backup folders, they are all on the cache drive which is an SSD and I don't have to worry about spin up.


Yeah, and cache-dirs only caches the dirs. Programs don't care much about dirs, they care about the file content, so it would make no difference what-so-ever to cache a programs directories. Well except for synchronization / backup software that acutally scans folders to see what files they contain. 

Also, my cache-disk is SSD, no need to have cache-dirs scan it. I'm still looking forward to the day when my main used disk is also an SSD, but it wouldn't make a huge difference until the parity is also an SSD.

I cache the stuff, where I notice I have to wait for disks to spin up. If it is unlikely to keep me waiting, no need to cache it.

Link to comment
  • 2 weeks later...
7 hours ago, Danuel said:

 

did anyone make this work ? because for me is not working  :(

11.png

I have my Cache pressure of directories on system set to 1. not had an issue with memory running away.

Apart from that my settings are the same i have limit the memory available set to 0 which was default.

 

When Plex for example does a scan over my TV Folder when a new show is added it doesn't make the disks spin up because the files are in cache.

But when Plex runs its Maintenace daily it always spins the disks up not sure if thats because it's doing more than just looking at files in a scan. It's more a Plex issue than a cache dirs issue.

 

 

Edited by Maticks
Link to comment

Just reading through this thread, one thing that might be related is the reported speed difference using ls on /mnt/user - https://forums.unraid.net/bug-reports/stable-releases/680-slow-shfs-file-listings-r818/

 

it seems the high CPU usage could be due to the find crawling that shfs aggregated folder.

Edited by GraemeT
Link to comment
On 9/7/2017 at 12:14 AM, coolspot said:

Is Cache_Dir incompatible with OSX? It seems OSX will do a disk read no matter what, leading to it bypassing the directory cache?

 

I wonder if OSX is trying to read the .ds_store file containing the folder meta data.

 

If so, it would be good if unRAID has some way of keeping the .ds_store file on a SSD cache, thereby negating the need to spin up the whole array to read these small files. Does anyone know if there is a way to do that?

 

I've just had an idea for this.  With Squid's Mover Tuning plugin, I have set an exemption for file type '.DS_Store'.   Now I'm going to delete all previous .DS-Store files and *hopefully* the new ones will stay on the SSD cache.  I'm wondering if this is the root of many Mac users' problems with cache dir.

Edited by acosmichippo
  • Like 1
Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.