I have a 6-core i-7 10th generation new laptop. Dropbox is using 30-35% of CPU even though synching is up to date. I've stopped and restarted the app, I've rebooted, etc. with very little help. On occasion it drops to 10% or less but mostly it stays real high.
I probably wouldn't care except that it drives up the temp and gets the fan going like crazy on my laptop. Music or other audio use of my laptop is about useless if Dropbox is running.
Any suggestions? What CPU utilizations are others seeing from Dropbox?
I have 858,000 files. Yes, I know it's over 200K but it's up to date and 90% of those files never change so the documented CPU problem for large file numbers doesn't apply - it explicitly states:
1) The desktop app is syncing a large number of files
The desktop app may cause high CPU usage if there are a large number of files to sync. This is especially true the first time files on your computer have been synced.
Since the sync has been mostly up to date for 2 weeks, that's not the cause. And I say "mostly" only because sometimes I kill the Dropbox program to get some peace from the incessant fan noise from my new HP laptop caused by the high CPU utilization in Dropbox. When I do that, it might take a few minutes to resynch and then I can, sort of, understand the CPU utilization.
Interestingly, there are a lot of files with only read access that Dropbox is failing to sync. The sync error states that it can't upload because it doesn't have access to the file but it has read and read/execute permission.
I keep my music library on my Dropbox folder but I make all my album art read-only to even admin accounts with only a special account having full control; I use that account only for resolving or updating album art. The reason for this is that Microsoft Windows Media Player will erase my high-quality, custom, album art and replace it with 200 x 200 pixel junk art and the only way to prevent Microsoft from destroying my files is to never, ever, run Media Player using an account that has write permission to the album art.
But I would challenge this exception because Dropbox should not need write access to my files in order to synch them unless there's a newer change from a different device - and there never, ever, is. I create the art, set ACLs to lock it down, and never touch those files again.
So the permissions might be the problem but Dropbox should not require write permissions to the source and, even when it does require it on other devices, why would it continuously try to sync failed files? That's what they call crazy; doing the same thing over and over again and expecting a different result - and only a crazy computer program can do the same thing literally trillions of times over and over again and expect a different result. Flag the file with an error and quit being crazy. 😁
Just FYI, about 750,000 of the 858,000 files are multiple copies of node.js directories. I still think it's a bug to have CPU utilization issues based on file count when files are all up to date but I am most interested in resolving the issue so I'm moving all my development work outside of Dropbox and will use more selective synching along with github to replicate files between devices.
Even if the files are up to date, the app still has to technically monitor each file consistently to see if there is an update on the site, hence the CPU usage. If you're syncing more than 300k files onto your machine, then you can get these issues.
Read-only files could also generate errors depending on how they're locked.