Continued corespotlightd process CPU overload issues

This was a no-go for me, I'm afraid. Several hours after turning off AI, I opened the triggering Pages document and within 15 minutes or so was right back in beachball city.

Rollwagen wrote:

I checked Activity Monitor on my M2 MBA 8 hours after turning off Apple Intelligence and the CPU usage for corespotlightd was 0.0% !

I've found a couple of ways to reduce the process load, but it's always temporary. Deleting the plist as I first suggested does it for me, but perhaps because this plist is modified by the OS every night, the issue comes back the next day. Possibly any large processor demand is the trigger. For me, the process always falls back into a tolerable range 10-15 minutes after closing the triggering Pages document. Thanks for being our emissary to Apple Support. I know how time consuming this can be. Looking forward to your report!

Rollwagen wrote:

Turning off Apple Intelligence on my M2 MBA macOS 15.2 stopped corespotlightd from hogging the CPU, dropping the process from in excess of 250% of CPU to 0.0 % within 8 hours. However, when I went back into my Pages doc (currently 1.2 MB, stored on iCloud), I continued to experience the spinning rainbow wheel, although less frequently and for less time. I've also experienced hesitation in my other apps (including while typing this post!), but no spinning wheel. I've talked with a member of the Senior Support Team at Apple and have arranged for them to collect data for Engineering to evaluate. That happens this coming Tuesday (my schedule doesn't fit with theirs until then). As much as we all don't like it, it appears it's a problem we'll have to live with for a bit until Engineering can figure out what's happening

Good to hear this update helped you, but I am running 15.2 on all of my Macs (3) and still have the issue on one of them.

SBML wrote:

After installing macOS 15.2 earlier today, I cannot reproduce the issue. Apart from a single Google Chrome Helper (Renderer) process massively hogging the CPU (which did not return after a force-quit), I've gone from having 27 stuck processes with corespotlightd hogging the CPU to zero stuck processes and corespotlightd very occasionally flashing up in the top-5 of the usage list then vanishing again. No more spinning beachballs. No data entry issues. Time Machine drive reconnected and working. Fingers crossed this has fixed the issue.

I don't believe this issue is exclusive to Pages, as I have seen it elsewhere, but it seems to be triggered most reliably by opening large documents in this app. Close the document and the process falls back to a normal range in a few minutes, usually. Time Machine is working properly for me, though it could still be implicated in the way you suggest.

Maybe off-topic, but perhaps helpful for your Time Machine issue: TM maintains a library of backup images on the backed up volume, so it might not address an issue with a corrupted TM backup by starting with a new backup drive. You might try forcing TM to verify the existing backup. Control-click on the backup drive in System Settings/General/Time Machine and select "verify" from the popup menu. If it can't be verified you will have the option to delete and backup from scratch. Worth a try.

ericmurphysf wrote:

I've had similar problems with all four of my Macs (a Mac Studio with an M1 Ultra, a MacBook Pro with an M2 Max, an iMac Pro, and a 17-inch 2020 iMac with an 8-core Core i7). On all four systems, I noted sometime around when 15.1.1 came out that corespotlightd would frequently top the list of processes, using anything from 100% CPU all the way to 750%(!) of CPU (on the iMac), causing the fans to spin up on the Intel systems to annoying levels. Updating to 15.2 did not resolve the issue for me, and in fact may have worsened it.

I did notice that corespotlightd calmed down quite a bit simply by closing a large Pages doc (200+ MB), and even more reliably by simply closing Pages on systems where I wasn't actively editing documents (at least, documents that are synced to iCloud). Corespotlightd will still occasionally ramp up to 100+% of CPU, but it won't stay there indefinitely, and most of the time it will be under 50%.

But another more serious issue: I found that after I installed 15.1.1, I could no longer back up the Intel systems via Time Machine. If I tried, one or both situations would arise: (i) a Time Machine backup would be "preparing" for hours or even days; and (ii) attempting such backups would frequently lead to repeated kernel-panics. The only resolution for this latter issue I have found is to disable Time Machine backups entirely. Even starting a backup on a freshly-erased backup drive with no existing Time Machine backups would still lead to the same behavior vis à vis interminable "preparation" of backups and repeated kernel panics.

One thing occurred to me during all of this trouble-shooting: I believe that Time Machine relies on Spotlight to identify files which have been modified since the last backup. I think it may be there is some bug in corespotlightd that aside from consuming vast system resources, also leads to complete (albeit short-lived) system freezes where they don't cause a kernel panic, and also interferes with the proper operation of Time Machine.

Curiouser and curiouser. Good this worked for you, but I've already established that moving a document that triggers the process from iCloud to my local drive does not change the behavior. Also, other Macs on my network don't have the problem. We also have very fast service, 225 mbps down and 22 up. So I feel I have completely eliminated network speed as a possible culprit, at least in my case. Looks like I will have to get on the phone to Apple eventually.

Rollwagen wrote:

Update: Slow upload data speeds appear to be causing lags/spinning wheels while working in my larger Pages documents on iCloud. I often work at remote locations using a VPN. I have no control over the upload speeds on these remote Wifi connections (community college Wifi, coffee shops, etc). So, I moved my large Pages files off iCloud drive to my computer drive. Since moving the files, I have not encountered any issues high CPU usage, lags, or spinning wheels while working on those documents. Emboldened, I turned on Apple Intelligence and so far, everything is working perfectly. No processes are hogging the CPU and there are no delays/spinning wheels while working within any app, including Pages.

One more piece of curious business. Today I added an external drive back into Spotlight indexing, a disk loaded with PDF files. Immediately this invoked the process "CGPDFService" in four separate threads. If I understand properly, this service indexes PDF files for Spotlight. Activity Monitor reports each process takes up a nearly identical 90-98 percent of the CPU but with roughly 80 percent of the CPU idle. They have been running for over two hours now but without slowing the Mac down to a crawl and corespotlightd hasn't approached the top of the list since.

This is interesting but I am not sure what to make of it. The store.db file I found at the first path on my Studio is 17.7GB. I guess that's kind of shocking, but only without checking it on any other Macs to see if it's normal. You might watch yours to see if it grows. It's tempting to try to removing it, but that directory contains 224 files, including several others that are quite large, so this seems like a long shot and potentially a risk.

SBML wrote:

Offering some additional info that may or may not be useful.

When I was experiencing this issue (before updating from 15.1.1. to 15.2), there were two very large store.db files in the meta data:

Library/Metadata/CoreSpotlight/Priority/index.spotlightV3/store.db

Library/Metadata/CoreSpotlight/NSFileProtectionCompleteUntilFirstUserAuthentication/index.spotlightV3/store.db

Both were over 11GB each.

Since updating, when I'm working with iCloud-based Pages files, although corespotlightd occasionally shows on Activity Monitor taking over 300% of CPU, it doesn't stay long or create any persistently stuck processes, cursor freezes, or data entry issues. However, those store.db files have now been reduced to 24MB and 193MB respectively. From GB to MB has got be an improvement, right?

By any chance did you look at the graph at the bottom of the Activity Monitor window when this was happening to see how much of the CPU remained idle? I still think it is odd that this process can be reported as taking up 100 percent and more of the CPU in the process list, when the summary at the bottom of the window shows the CPU as rarely being less than 80 percent idle.

ericmurphysf wrote:

Just for, I don't know, comic relief maybe: I came home today to find that corespotlighd was using 1,400% of available CPU time on my 8-core iMac Pro.

How the system avoided crashing completely is a bit of a mystery.