(OS X) Dropbox consuming a lot of CPU whenever any file or folder is changed anywhere

[Dave H.]

On my OS X 10.9.5 system I'm seeing Dropbox consume CPU whenever anything on the file system changes, regardless of whether the changed files or folders are in the Dropbox synced folders. The CPU usage is proportionate to the rate of file system changes.

When I'm running an installer that takes a long time and has high disk activity (e.g. installing a documenation update in XCode), then the Dropbox CPU usage goes through the roof and I see the Dropbox sync status change from 'up to date' to 'indexing'. For less sustained activities with less intensive file system changes, I see Dropbox just popup briefly in the list of top CPU consumers -- but it shouldn't be showing up at all (or certainly not at double digit CPU use and not for the duration of the file system activity.

My guess is that Dropbox is simply listening for file system events and reacting to each one as if it might be change in a synced file or folder. It should be ignoring fsevents that are for items outside the Dropbox folders -- but it seems not to be the case. 😞 😞

I'm on 3.0.3, but have been seeing this problem since the 2.* days.

--
Dave Hein

[Amandeep R.]

Have you guys figured this out yet? I can't afford to have my CPU over 100% as it makes my computer slow. Can't you guys cap your Dropbox app to use only maybe 20% of CPU time? If you think this is not enough then you guys just have a bad design or poor developers. Figure it out or I am looking for another solution.

[Roberto r.15]

Yes, I did, Google Drive is the way to go. 

It's sad, because I like Dropbox, but I can't afford having this 100% CPU problem, my computer heats like hell, and this reduces the lifetime of my processors, so I'm not going to pay for a service that does that, it's like paying it twice.

Sad but true.

[Taylor R.4]

I found this thread a few minutes ago because I haven't had this issue until today. For the past two years Dropbox has worked silently in the background but today it decided to be running at 50% CPU all the time. I haven't changed anything recently.

[Sebastian K.6]

I have the same issue: Every time I make any operations which modify a lot files anywhere outside the Dropbox directory Dropbox just consumes 100% CPU. I can reproduce this issue easily by just extracting a very large tar file (e.g. the Linux kernel sources) somewhere outside the Dropbox directory: Even with a completely empty Dropbox directory (that obviously contain no symlinks) I get a very high CPU use of the Dropbox process even though not a single file in the Dropbox directory was modified.

I attached DTrace to the Dropbox process and can see it making thousands of system calls per second when I extract the tar file somewhere outside the Dropbox directory:

Dear Dropbox developers, are you *sure* you're not listening to *all* filesystem events which happen in my user's directory? Because to me it completely looks like that and is the reason I get such a high CPU use when I make heavy filesystem operation which shouldn't bother Dropbox at all.

[Neven J.]

Bump!

I am having exactly the same issue with exactly the same findings on multiple MacbookPros.

Did not get much love from Dropbox support. They tried but failed miserably and they ignore the issue.

Dropbox support performed stack analysis remotely (without my permission or knowledge) and saw my running process was TimeMachine. They think TimeMachine is causing clash and asked me to raise issue with Apple LOL.

For test I reinstalled dropbox and osx, disabled timemachine, checked symlinks, ownerships, permissions,  etc etc...  - and high cpu is still here.

I do not have this issue on Windows on other hand.

[Darwin I.]

I'm trying their suggestions like removing directories with symlinks, but my Dev folder where I keep many python projects seems to be the one with all the sym links. I'm moving that to Google Drive I guess since Dropbox can't handle symlinks? Seems extremely lame. 

[Kevin B.69]

Dear Dropbox,

I'm discontinuing my paid membership over this issue. I was an avid member early on ever since the beta (2007/2008?), but I'm no longer impressed. In fact, I'm hugely disappointed. This CPU usage issue has remained for far too long (past couple of years for me). At this late stage it is not even clear if you are treating this as a bug.

I have read the posts about 300,000+ files, and symlinks etc. And my situation is probably one of those, but you know what - I don't care. I want to have 300,000+ files! and I want (need) symlinks! And I want to use my computer without hearing the fan run furiously.

There is no reason that the desktop sync app should cause such high CPU for such long durations even with these conditions. The app should just work quietly in the background without disturbing computer usage. Throttle the heavy work. Yield CPU in your tight loops. Your smart engineers can solve this problem.

[Steven G.6]

I seem to have the same issues as Sebastian K. and others, basically anytime I modify a file or possibly install or update a package through homebrew it will start using a high % of CPU, 90-100 and for no good reason... at least I don't see why it would need to be reading activity outside of the Dropbox folder especially when I'm not using symlinks inside of it.

Something is afoul here.

[Roberto r.15]

Steven G., Sebastian K., Kevin B., 

As I could note, you are programmers.

Did you notice that Dropbox now has only one plan 1TB $9.99 monthly? 

They don't care about programmers, they wanna build an average service for an average person that will use 10, 20GB only and will not complain because they will never need to store the same amount of files programmers need. They will never open a terminal, use brew or npm, use symlinks, etc. They don't care about fixing this, they prefer us to leave and charge average people for an average service that will make these casual users very happy.

Shame on you Dropbox.

[Neven J.]

I switched to self hosted seafile and won't look back. Dropbox does not care about user experience at all.

It's a SHAME that their client on macOS is such CRAP, and at the same time there is so much GREAT code from dropbox on github with all sorts of experiments in different languages, more optimized that python for file hashing - https://github.com/dropbox/