[Plugin] Consistent CPU Spikes though Dynamix Cache Directories


Stroker

Recommended Posts

Hey Guys and Girls!

for a few Weeks a got a very strange Problem as drescribed in the post here with Screenshots and my diagnostics file.

To put it short I get consistent CPU spikes as high as 25 to 40 or nearly 50 % with activated Folder Caching, They appear as often as the setting "Maximum interval between folder scans (sec):" is selected.

 
What was not discribed in the last post was the log of the Plugin itself at /var/log/cache_dirs.log . I have attached this as txt file to this Post and also a fresh Screenshot of the graph in the Statistics Plugin. This is with all settings at default and excluded all Backup or Cache Folders.

In this it logs like 5-14% CPU Usage but in the Statistics Plugin I get much higher CPU Use as seen in the referenced Post or the Screenshot. With the unlimited deph I get nearly 122k files. The same Usage and nearly the same Spikes appear when the depth is fixed at 5 with arround 59k files. Should this usage be this much with a i3-3240? Shoudn't it scale accross the load of files? or are this Spikes anormal?

Bonienl
in the linked post said that he couldn't explain this spikes to himself either but sadly had no idea how to proceed. Does anyone here have any idea how I could troubleshoot this problem further?

Best Regards
Stroker

folder_caching_logs.txt

screen_0809_2018.png

Link to comment
  • 6 months later...

I got no clue either. I've tried to get Dynamix Cache Directories to work without spikes for years. Either I disable User Shares and have lower CPU usage and get disk spin ups while accessing the network share. Or I enable User Shares and get high CPU spikes and still get disk spin ups. I don't think the plugin quite works as it should, default settings or not. The only way to get the cache plugin to work properly is to disable it.

 

You'd think there would be some form of low level disk API that could be used to access kernel level disk usage to build a directory list and be done with it in 1 minute. Then any time the kernel sees a write to a directory the drive is already spun up and it gets added to the cache in a split second. That way 24/7 CPU spikes while scanning for the cache is not necessary. But who am I tell them how to program their software. I'm just an end user who paid money for it.

Link to comment
  • 5 weeks later...

Thanks for the Info. Sadly appdata is already excluded and the Problems persists on my Side. I will try to fiddle around with the depth a bit.

Currently the Plugin is disabled but I had a little more time to investigate the Problem.

I will post Updated Logs and my new findings.

Edited by Stroker
Link to comment
  • 8 months later...
  • 4 years later...

hi, apols for dragging an old post up. I have just tried this plugin on 6.12. I get the same behaviour, big CPU spikes every 5 seconds and the system slows down. I removed it and all back to normal. Did anyone find a reason for it.... i likes the fact my disks didnt spin up when browsing

 

  • Upvote 1
Link to comment

Be sure to set up cache_dirs to only cache the shares that you want included.  If you don't specify the included shares, it will cache anything it finds at /mnt/.  Things like the system share don't need to be cached and will definitely put a load on cache_dirs.

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.