I am trying to diagnose very high CPU use by cloudd after upgrading to Sonoma recently.
I am using EF 1.9.12
My EF library is at /Users/lol/Library/Mobile Documents/com~apple~CloudDocs/EagleFiler Libraries/Main Library/Files (aka in iCloud Drive).
When cloudd is running hot (600-800% CPU on my MacBook) and I inspect it’s open files, I am currently seeing things like
However, at the moment I’m ready to post this, these entries have finally gone away, of course! So maybe not something with EF at all. No (obvious) EF file open by cloudd at the moment and it’s still at 835%.
In the Finder the iCloud Drive spinner icon is lit and it is trying to “Upload 1 file”, which is 2.7Mb and taking forever. It seems to do this every so often throughout the day.
I’ve not received any reports of problems with EagleFiler and iCloud Drive on Sonoma. Maybe a utility like Cirrus could help you figure out what cloudd is doing.
I’ve continued to struggle with extreme high CPU and load issues with cloudd and believe I have identified it as related to EF.
Whenever I am running EF, cloudd struggles to upload Main Library.eflibrary (this file is 600MB) and .EagleFiler Metadata.plist at the top level of Files (2.7MB).
If I quit EF and do a killall bird && killall cloudd, those EF files immediately begin to sync to iCloud and do finish. Things are calm until I relaunch EF.
I thought maybe 14.1 macOS might help, but it made no difference.
Yesterday I disabled the macOS feature “Sys Prefs → Apple ID → iCloud Optimize Mac Storage” as I don’t recall I ever had that on prior to Sonoma and thought maybe it was a new default). That finished pulling things down and it made no difference either.
Yesterday I quit EF, killall bird && killall cloudd and went about my business. All things were calm until this morning when I started work and launched EF. cloudd got stuck on Main Library.eflibrary and my MacBook became unusable with high CPU/load. I quit EF, restarted bird/cloudd, cloudd did sync, and things remained calm until I started using EF again.
I researched methods to exclude cloudd sync of particular folders and files. It seems you can add an extension (after the “real” file extension) to exclude it, but I wonder if that would break EF.
Alternatively I could move my EF library out of iCloud Drive, but I put it there so I could access everything in “Files” on my iOS devices.
I’m not hearing other reports of this, but it does seem as though Apple rewrote iCloud Drive for Sonoma. The .eflibrary file is actually a package (folder). Are you able to see with Cirrus which files inside it are bogging down the syncing?
EagleFiler does keep a Temporary Items.nobackup folder inside of the .eflibrary, which sees lots of new files, but they’re all inside of a iCloudDrive.nosync folder, which should prevent them from being uploaded to iCloud.
If it’s the Records.efindex, that’s not excluded from syncing, and that file can indeed be large. But it’s just a regular file. That shouldn’t cause iCloud to use lots of CPU unless there’s a bug.
One option would be to move the whole library folder out of iCloud Drive. You could then move the Files folder to iCloud Drive and replace it with an alias. That way you would still be able to access the files from iOS, but the indexes would not sync.
I like your suggestion to move it so just Files are in iCloud Drive, but that still leaves the .EagleFiler Metadata.plist at the top level of Files to contend with.
I take a look with Cirrus before I move things to see if I can tell what file it is, but it’s syncing around 500MB, so I presume it’s the Records.efindex file.
I’ll set it up like you suggest and at least get the big 500MB file/package out of the mix first. Then it’ll be easier to see what is causing any further issues.
I launched EF and immediately the iCloud Drive says it’s uploading 500 MB consisting of 2 files.
Cirrus shows me Main Library.eflibrary has an “uploading” status, but when I drill into Main Library.eflibrary, Cirrus doesn’t show a status for any of the items therein. All the status boxes are blank for all files inside the package file/dir. Maybe a bug?
The weird thing is cloudd is using 600-800% cpu while it’s uploading these 2 EF files. That in itself should never be happening no matter what it’s syncing. Ugh.
At the moment syncing activity has stopped, the icon next to the “iCloud Drive” line in the Finder sidebar now has an exclamation mark in a spinning arrow circle, and the CPU is pegged. It says “iCloud Status There are pending items to sync.”
I’m going to move stuff around like you suggested now and see how it goes.
I wonder if iCloud Drive has changed so that it now sees the entire package as a single unit to sync, so that it no longer even looks for the .nosync exclusions or tracks progress for other files inside.
Agreed. Nor should a 2.7 MB plist file cause problems.
File is now by itself in iCloud Drive. I made a symlink to it in the EF library dir.
So far so good. That’s 500MB less in my iCloud Drive as a bonus.
Interestingly iCloud didn’t seem to resync “Files” even though I moved it out with the library and then moved it back into iCloud Drive in a “different” path. All the files are still immediately accessible on my iPad. So I guess it does have some smarts.