QRecallDownloadIdentity KeysForumsSupport
  [Search] Search   [Recent Topics] Recent Topics   [Hottest Topics] Hottest Topics   [Groups] Back to home page 
High CPU usage  XML
Forum Index » Problems and Bugs
Author Message
Andre Kaltenbacher



Joined: 11-Feb-08 05:45
Messages: 7
Offline

Hi James,

I have noticed a high cpu usage the last weeks. There are two processes with high cpu usage during the backup:

– QRecallHelper
– cfprefsd

Both processes use about 120-130%.

I back up my encrypted full HDD to an encrypted external HDD via USB3, but the backup seems to be very slow. Sometimes QRecall needs one minute to "process" (Capturing [file]) a file that hasn't even changed since the last backup. Usually I stop the backup, because the sound of my fast spinning laptop fans annoys me so much

Any ideas?

James Bucanek



Joined: 14-Feb-07 10:05
Messages: 1478
Offline

Andre wrote:I have noticed a high cpu usage the last weeks.

This is a bug in OS X. It’s been around a while, and I really wish Apple would fix it.

It’s the result of a chain of events that starts when you choose the “Exclude items excluded by Time Machine” capture option. When you select this option, QRecall makes a special call to OS X for each item it’s about to capture that asks if this is an item that Time Machine captures (or ignores). That call queries a database and returns an answer.

The problem is apparently in the database query. It appears to grab exclusive control of the database using the system preferences service. System preferences were recently (OS X 10.7) modified to use on-disk semaphore locks to ensure orderly access to property list files. This is a good thing, and it’s all managed by the cfprefsd process, AKA the Core Foundation Preferences Daemon. But it’s also where the bug is: sometime those on-disk semaphore locks get set and never reset. When this happens, any attempt to aquire the semaphore results in a “spin lock” (a tight code loop that continuously checks the status of the lock, using 100% CPU) that goes nowhere and does nothing.

Back to QRecall. As QRecall checks every file to see if it needs to be captured up or not, it queries OS X, which then "spin locks" waiting to access the database. Instead of returning an answer in a fraction of a millisecond, it chews up 100+% CPU time for almost a second—thousands of times slower than it should, and at a huge cost in CPU resources. And, of course, this repeats for every single item QRecall is considering.

You might be able to avoid the problem by restarting your system. Most of the semaphore files will be reset when the system restarts, allowing cfprefsd to run efficiently again. If that doesn’t work, you can always turn off the “Exclude items excluded by Time Machine” option.

This message was edited 1 time. Last update was at 27-May-14 19:11


- QRecall Development -
[Email]
Andre Kaltenbacher



Joined: 11-Feb-08 05:45
Messages: 7
Offline


That was easy! Everything is fine now.

Thank you.
 
Forum Index » Problems and Bugs
Go to:   
Powered by JForum 2.1.8 © JForum Team