-
-
Save drblue/6fdc431396760f2440ce to your computer and use it in GitHub Desktop.
#!/bin/bash | |
## Fix OneDrive for Mac CPU usage | |
## | |
## Seems this is still a problem 5 years later after I created this little gist. | |
## I have long since stopped using OneDrive (luckily), but according to | |
## comments below, I have added the new path for OfficeFileCache for macOS | |
## Mojave (10.14) and Catalina (10.15). | |
## Run this on macOS Mojave (10.14) and Catalina (10.15) | |
find ~/Library/Containers/ -type d -name OfficeFileCache -exec rm -r {} + | |
## Run this if you're on pre-Mojave (< 10.14) | |
find ~/Library/Group\ Containers/ -type d -name OfficeFileCache -exec rm -r {} + |
The only thing that really helped in my case is OneDrive Reset
This script does not seem to fix the problem of distnoted, onedrive and onedrive finder integration going wild on my 2 macs. Despite reinstalling macos and reinstalling onedrive, the problem is still there. Only way I got it to calm down is to use AppPolice (https://github.com/AppPolice/AppPolice) and restrict these processes to 20-30% max usage.
This worked well for me after trying many other solutions. Resetting OneDrive only helped for some days and it would still come back.
(Using macOS Catalina 10.15.7)
I had this problem earlier and ran the script and it fixed it for some time. Came back again later. I then decided to search for a different approach and looked for a way to prevent Onedrive from using excess CPU. I then ran into AppPolice which does just that. I now limit OneDrive and OneDrive Finder Integration to 50% CPU and everything's fine. When i find any app that goes over the 100% limit, I then research the issue and if I find multiple users have had the cpu issue with no resolution, then I just limit that app as well. you can get AppPolice from the following link. I'm using it on Big Sur - 11.6. Hope this helps others on this post.
For people with crazy idle OneDrive CPU usage, you might want to try disable the auto start in OneDrive's own settings, and enable it through SystemPref -> Users&Groups -> Login Items (tab) -> + OneDrive to the list. There seems to be an issue with how OD (and Dropbox for that matter) handle their own startups. Maybe your problem is caused by that, but of course, your milage may vary. At least it's a safe method to try.
Disabling autostart in OneDrive's settings reduced the CPU load instantly and has kept low for 2 days now, few restarts. In the meantime I deleted ca. 200,000 files on the Onedrive cloud (which has been excluded from sync to the computer, however). So cannot determine which part of my scenario has been the key one, but disabling autostart within Onedrive's properties seems to help in my case. It brings no harm, so why not trying?
Improved the script to kill all alive procecess regarding onedrive. If you want to reopen it you can pass ass first argument the word open and it will resatrt onedrive. Otherwise it will shut OneDrive off. This really helped me because it kills all the 'OneDrive Finder Integration' procecess that was what was overheating my computer.
## Fix OneDrive for Mac CPU usage
##
## Seems this is still a problem 5 years later after I created this little gist.
## I have long since stopped using OneDrive (luckily), but according to
## comments below, I have added the new path for OfficeFileCache for macOS
## Mojave (10.14) and Catalina (10.15).
_open=${1:-not}
## Run this on macOS Mojave (10.14) and Catalina (10.15)
find ~/Library/Containers/ -type d -name OfficeFileCache -exec rm -r {} +
## Run this if you're on pre-Mojave (< 10.14)
find ~/Library/Group\ Containers/ -type d -name OfficeFileCache -exec rm -r {} +
# Kill one drive procecess
killall OneDrive
ps aux | grep OneDrive | awk '{print $2}' | xargs kill -9
if [ "$_open" != "not" ]; then
open -a OneDrive
fi
High OneDrive CPU use might also be a consequence of your antivirus software's on-access scanning. I found I had huge CPU use in One Drive for the last two days, and hence found myself here. I wondered about my anti-virus (BitDefender). I switched it off temporarily, and One Drive CPU use returned to something low. I then switched BitDefender back on and OneDrive CPU use remained low. I suspect that BitDefender and One Drive syncing had got themselves into a mutually dependent loop, and switching BitDefender off broke that loop.
In my case, I needed to reinstall all Office 365 apps. That helped for a while. I noticed that the problems returned after using software to clean my Mac. So I reinstalled it again and blocked in OneDrive all apps which can try to scan the whole storage.
I have two ideas about what may cause the problem:
First, some apps try to access all files, which creates problems. But in this situation, OneDrive should try to download all files.
So more practical is the idea that in temp files, OneDrive storage some vital information about sync status. Then cleaning apps delete the files and break OneDrive.
I am not sure if I am right. Although I reinstalled Office two weeks ago, OneDrive works correctly again from this time.
I have macOS 13.2.1 and OneDrive (OD) 23.048.0305.0002 (standalone). I was tired-up of this OD for a long time since they removed the system kernel extensions support. I have over 200k files of 780 GB of data. Although, I noticed the OneDrive macOS app of 2018 was terrible with high CPU usage and memory. However, it improved over time, and after December 2021, the fileprovider (removing the system kernel extension support) messed up OD. This was the problem from the end of 2021.
I was reluctant to use OD's Files On-Demand feature on mac, as I needed them even without an internet connection. Yesterday, I reset the OD on mac, which is now on the Files On-Demand. I do not see any spike in CPU and memory usage. However, sometimes it says processing changes for an extended period of time when syncing 365 files. I will observe the behavior of Files On-Demand for some time to come up with a conclusion.
I hope this helps someone if they have a similar issue.
does this manifest with extended delays in Open/Save modal dialogs with some indiciates that something is horrible wrong in XPC-space?
Contacted the
Microsoft Premier Support
and the reasonOneDrive
has problems onMac
(and I guess not only) in my case was a higher amount of files than 300k. It was a bit strange for me, because for a looong time never had such a problem, even withnode_modules
in theOneDrive
. Sadly, once the problems araised I've kept the setup for several months causing my battery to... die faster. Please don't do it :)As stated here: "For optimum performance, we recommend storing no more than 300,000 files in a single OneDrive or team site library. Although SharePoint Online can store 30 million documents per library, for optimum performance we recommend syncing no more than 300,000 files across all document libraries. Additionally, the same performance issues can occur if you have 300,000 items or more across all libraries you are syncing, even if you are not syncing all items in those libraries."
The support.microsoft.com article provides the same information.
My problem was the
node_modules
folder. I've found a nice solution regarding Dropbox to ignore this file, but it doesn't work onOneDrive
. It's also in the official help docs, as stated here: Once ignored, the file or folder remains where it is in your Dropbox folder on your computer’s hard drive, but it’s deleted from the Dropbox server and your other devices, can’t be accessed on dropbox.com, and won’t sync to your Dropbox account.I've tried to use a similar solution
Dropbox
has, but then the localnode_modules
is being deleted, as stated here: If you uncheck a folder you are syncing to your computer, the folder will be removed from your computer. The folder and its contents will still be available online.I've seen a couple of hacks, like here, but I've decided to simply keep my projects on
OneDrive
without thenode_modules
. Once working on the project, simply moving it towardsDownloads
, which isn't synchronized with any cloud. In that case, I do have to remember togit pull
in the OneDrive folder to keep it synchronized. That's a backup anyway, because the source code is of course onGitHub
/GitLab
/etc.