Continued corespotlightd process CPU overload issues

I can't add a great deal to what has been reported apart from that I do not have this issue on a Desktop running on an Intel processor, only on my MacBook Air with an M2 processor. One difference between the MacBook and the Desktop is that Apple intelligence software can't run on an Intel processor.

I did turn Apple intelligence off for an hour, restart it and after an hour the corespotlightd process has become dormant - maybe just a coincidence

MC2G wrote:

I have checket and I also have a store.db file of 17,51 Gb and another one of 1,91 Gb.

What soul I do about it? Can I just delete them?

I'm not sure what you mean by "store.db" files. What I did was destroy the contents of my CoreSpotlight and SpotlightKnowledgeEvents files (but not deleting the enclosing folder itself), as suggested by ericmurphysf. It's been about 18 hours since I did that and the fix has held.

I will add to this discussion the following webpage that a friend of mine hipped me to; it seems to corroborate ericmurphysf's advice: https://www.spyhunter.com/shm/fix-macos-sequoia-spotlight-issues/. Yes, they have software to sell, but they advocate deleting the whole CoreSpotlight folder (which also contains the SpotlightKnowledgeEvents on new computers) and deleting another Spotlight folder in /System/Volumes/Data/.

Now that my Time Machine backups are working again, I will probably try the above the next time the corespotlightd process gets too big for its breeches. After less than a day, it's up to 21.41 GB. I wish I noted how big it was before I cleaned it out. Going forward, I request people let us know how big their CoreSpotlight folders are before they delete them.

Mitch Stone wrote:

I'm not sure what you mean by without migrated data, though. My files and apps were manually migrated on the Studio.

I meant migrated automatically, using the migration assistant. On my M3 air I did not use migration assistant at all, and that machine is not affected by this problem.

Some of the theories for the origin of this issue are interesting but probably have to be treated as theories. As I've mentioned in previous posts, since the last time I deleted the spotlight plist, I have not been afflicted by this issue. It's been a couple of weeks now.

It's interesting that you've had good success with only deleting that plist file. I had previously deleted almost everything, and the problem came back.

I have just now again deleted the entire corespotlight folder in (in the library folder) and the preferences file you mentioned, but I think I see the corespotlight folder already growing again. We'll see.

Bets wrote:

Thank you for this clear summary. I have developed this problem. I AM using large Pages files. The problem developed after one of the fairly recent system updates. I'm on an M2 Air 8 mb memory running 15.3. I am a heavy but ordinary user who is NOT comfortable deleting random files or using Terminal. Can you give us some simple instructions until APPLE fixes this problem. As the computer is quite Unusable at this point. It also has started crashing with the same error (can't recall - but something about devices not loading upon reboot).

To empty the Caches Folder:

Tab to Finder and in the Finder menu go to Go>Connect To Folder… and copy/paste „~/Library/Caches“. The Caches folder will pop up. Delete its contents. It’s generally safe.

To „reset“ or rebuild the Spotlight metadata (also called reindexing):

Either via the System Settings as explained by Apple here:

Rebuild the Spotlight index on your Mac - Apple Support

OR

1) Open the Terminal app.

2) Check if spotlight is running:

mdutil -s /

3) Turn off indexing (spotlight will stopp adding data when for example new files are being created):

sudo mdutil -i off /

4) Erase existing metadata (spotlight metadata will get wiped meaning the spotlight index will be erased):

sudo mdutil -E /

5) Turn on indexing back on:

sudo mdutil -i on /

After turning the indexing back on you will notice the index is being rebuild when you initiate spotlight with CMD+Space. It even shows you a blue progress bar.

In Short:

The system will automatically start reindexing afterwards unless indexing is disabled because you didn’t reenable it again by skipping Step 5) ( sudo mdutil -i on / )

At this point a restart never hurts. After that let it rebuild. Hopefully it gets smoother now. 😬

Mini notes:

1. If you disable indexing (-i off), Spotlight will not reindex after erasing.
2. If you have a large drive, reindexing may take several hours and impact performance. I have a 1TB drive with 15% space left. It took around 45-60 minutes.

PolyRod wrote:

Is spotlight indexing every minor variant of the document separately? Thus each time it saves a version, that gets indexed from scratch.

I'm pretty sure this is what's happening. The data structures in the ~/library/metadata Spotlight folders are very different between Intel and Apple Silicon systems, but on the former, I can open up a large .journal file in the /SpotlightKnowledgeEvents folder, say a 120 MB file, and find tens of thousands of references to the same Pages document that might only be 10 MB in size. This suggests to me that with every change in a Pages document that is saved in its version history (which might be every paragraph, or even every sentence), Spotlight re-indexes the entire document from beginning to end.

The procedure for deleting the appropriate metadata can be found here: Continued corespotlightd process CPU over… - Apple Community. If that link doesn’t work, you’re looking for a post that ericmurphysf wrote Jan 28, 2025 9:46 AM in response to Mitch Stone.

Me, too... Or, at least I am optimistic.

I just updated to MacOS Sequoia 15.4. I did not dump my growing daily cache of Metadata before update, so I will not be able to measure exactly until tomorrow. But, my current Activity Monitor readings are VERY ENCOURAGING!

Also my Apple Contacts seem to be working MUCH better. That application had been overloading, too, but I did not know if it was tied to latest CPU overload. Hoping for best.

Mitch Stone wrote:

I'd ask whether you are still seeing any performance hit along with the growing size of the metadata file. The real problem, practically speaking, is how the issue manifested itself as essentially unusable Mac systems. This is more critical than anything we see going on in Activity Monitor or in our metadata files. I can convince myself that this issue remains when I see occasional spikes in the corespotlightd and related processes, but these spikes are transitory. I no longer see any degradation of actual system performance, which was a huge and obvious problem before. So I would say, quit Activity Monitor, resist looking at that metadata directory, and just use the Mac for a while and see how it runs. I think that is how we determine whether Apple has slayed this issue in 15.4. My feeling is they probably have, at least for Apple silicon systems.

On my two Intel systems, I start seeing relatively minor performance issues when Spotlight metadata exceeds about 50 GB (which under 15.4 seems to take less time than it did under earlier versions of Sequoia). Mainly I see that smart folders in Mail take longer to update, and searches in Mail also take longer.

But I did't see severe problems on either Intel system until metadata was well over 100 GB.

All that said, I was having severe problems, especially with video playback, on my Mac Studio (but not on my M2 MBP) when metadata was very large on the two Intel systems, even though metadata on the Mac Studio never exceeded about 40 GB (the only thing connecting these systems is iCloud sync. I have no idea why (it could just be coincidence), but after I deleted excess metadata on the two Intel systems, the issues I was having on the Mac Studio vanished, so far (it's been two months) not to reappear.

YMMV, obviously, but what has kept me out of trouble so far has simply been deleting metadata from both Intel systems when it grows past 40 GB. I've seen absolutely no downsides to doing so, and the multiple issues, with Time Machine, Spotlight search, Mail smart folders/search, CPUs pinned, fans pinned, etc. have vanished. Having to delete these folders every couple of days instead of once a week on 15.4 vs. earlier versions is only slightly annoying.

I've been following this thread for months waiting for a solution to the same problem. The temporary fix of deleting the CoreSpotlight folder does help. After the 15.4 update, the problem went completely away for maybe a couple of weeks. Now it is back. One thing I can add is that, at least in my case, the CoreSpotlight folder is not very large: only 791MB. Yet the problem persists, particularly when pages is open, and especially when multiple pages documents are open at the same time.

My sense of things is that:

• It's not Pages specific; any iWork app can trigger it, with report of Numbers and Keynote. Pages is usually the culprit in this thread, but we just have more people working on many Pages docs, some of them large, and some of them with lots and lots of past versions.
• It's not iCloud specific, though it's possible that the iCloud versioning exacerbates the problem.
• No evidence that it's hardware specific, but I suspect that the older/slower your hardware, the more quickly the out of control metadata folder translates into cpu issues.
• I think the issue manifests with a confluence of factors, but it seems it can be traced back to a problem in versioning of iWork files, which leads to massive generation of metadata and problems follow from there.

Onyx, from Titanium Software is a free utility actually does delete these files for you. Under Maintenance, halfway down, you’ll see “rebuild the index” or “delete the current index.” Does exactly that. However, the OS will create new files in its place. So the process starts over again. If you delete the index, it does it safely. Until Apple fixes the problem.

I actually ran

nice -n20 bash -c 'while true; do killall -9 corespotlightd 2>/dev/null && sleep 2; done' &

this was actually running in the background consuming battery (at least less than corespotlightd would)

This horrid process not only is causing beachballing but is taking up ~60G in frivolous logs as well 🤬

b@Brians-MacBook-Pro-M4 CoreSpotlight % du -shc *


 28G	NSFileProtectionCompleteUntilFirstUserAuthentication
 
...

 27G	Priority


 56G	total