Continued corespotlightd process CPU overload issues

On my M4, tried

while true; do killall -9 corespotlightd 2>/dev/null && sleep 0.5; done &

this seemed to get rid of the process if run for a few seconds. But then opendirectoryd comes up and consistently uses about 20% of cpu.

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?

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.

Update: Running 15.3 on a 2022 M2 MacBook Air. I followed others and trashed the entire ~/Library/Metadata/CoreSpotlight folder 3 days ago on 2/10/25. Since then I only turn on Pages when I use it - which I have continued to do so. I also, split off some subtopics into their own documents so I wasn't having very large graphics heavy files open and editing all over the place in different sections. I do continue to save frequently- an old habit. My CoreSpotlight folder reappeared right away and the computer problems ceased. The folder is currently at 2.4 Gb compare to over 58 Gb when it was having difficulty. I have only 8 Gb of Memory if that matters. We did try one additional step before trashing CoreSpotlight. We turned OFF that process in the Activity Monitor. That seemed to cause a slight decrease in the folder size ~50Gb. But the effect was temporary of course as the process restarted.

Thanks to everyone - I hope Apple takes notice.

fcoteb wrote:

…Has someone else realised whether this issue drains the battery even when your MacBook is closed?

In my experience, yes. If I leave a Pages file, especially a large one with many edits, open on my M2 Pro MBP, the battery charge overnight with the lid closed can go from 100% down to as low as 40%.

fronesis47 wrote:

The temporary workaround• is to regularly delete the metadata folders.

The temporary and still very much less than ideal "fix• " is to TURN OFF spotlight indexing.

Any real solution• here will require Apple to make some tweak to spotlight or Pages.

Replying to my own post to amend it: It looks to me like the temporary fix is NOT a fix at all. I just turned spotlight indexing OFF, then opened a pages file and watched the corespotlight metadata folder grow over 5Gb in less than an hour. Whatever process is writing to the metadata folder is not turned off when you turn off spotlight indexing.

This means the only options are to live with this, by occasionally deleting the metadata folders, deleting the .plist file, and perhaps turning indexing off and on – all while waiting and hoping that apple fixes the problem.

I agree with Mitch Stone: it would be good to know if other documents (such as Numbers files) cause the same problem, and to see what happens with a new user.

THANK YOU to sugarskyline for showing me how to change the default presentation of the message board.

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.

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 2024 M4 Mac Mini was unusable: spinning beachballs, screen locking up for a few seconds. I tried several things—force quitting the corespotlightd process, Rebuild the Spotlight index on your Mac, turning off Apple Intelligence, deselecting all categories from Spotlight search—none of this worked.

I can confirm, that as instructed by ericmurphysf above, when I deleted the metadata out of the ~/library/metadata/Corespotlight and ~/library/metadata/SpotlightKnowledgeEvents (while leaving the folders themselves intact), I was rewarded with near-immediate improvement. Hopefully this holds up.

I'm wondering why I was affected and others not? One unusual thing about me is that I was upgrading from a 2014 Mac Mini. Maybe the jump from Monterey (OS 12) to Sequoia (OS 15) when migrating my old stuff over via Time Machine had something to do with it?

Mitch Stone wrote:

Did you try my suggestion? For me, it actually did help a lot. I'm not sure I understand the resistance to it, given the simplicity and apparent effectiveness. I'd really like to know if it works as well for others as it did for me.

Based on the totality of posts on this thread, it seems very likely that while using Pages is not the sole cause of corespotlightd (and Spotlight metadata) running amok, it seems to be possibly the largest contributor. So far, users seem to have had decent luck with one, two, or all three of the following:

1. Mitch's recommendation of duplicating a Pages file (thus removing versioning information, which seems to be what spikes corespotlightd activity and Spotlight metadata accumulation), and then making further edits to the duplicated version.
2. Removing Spotlight-related .plists.
3. Removing Corespotlight metadata from the ~/library/metadata folder(s)

None of these workarounds are permanent fixes. But they seem to buy at least temporary reprieve (I deleted Spotlight metadata yesterday afternoon, and right now the system fan is at 12%, system CPU usage is below 20%, and corespotlightd doesn't even appear in the top forty processes). If I have to delete metadata once a week or so (a task that takes all of ten seconds), that's a small price to pay for acceptable performance.

If you're running into performance issues, including Time Machine issues, I would recommend you try some or all of these fixes. Apple may or may not ever get around to addressing these issues (which seem to disproportionately affect Intel systems which are obviously not Apple's priorities these days). But these fixes, singly or in some combination, seem to work for a lot of people. I'd at least give them a try. None of them seem to have negative consequences, unless you're unusually dependent on versioning in Pages.

tl;dr — trash your ~/Library/Metadata/CoreSpotlight folder

I haven't had a problem since 11 February, when I was running macOS Sequoia 15.3. Then today, I noticed a lag when typing into a Pages document and then a spinning beachball when poking around in a Finder window. I fired up the Activity Monitor; corespotlightd was back to it's old tricks.

macOS Sequoia 15.4.1

Folder/File Sizes:

• /System/Volumes/Data/.Spotlight-V100 does NOT exist
• ~/Library/Metadata/CoreSpotlight at 62.45 GB
• ~/Library/Metadata/CoreSpotlight/SpotlightKnowledgeEvents at 7.4 GB
• ~/Library/Metadata/CoreSpotlight/NSFileProtectionCompleteUntilFirstUserAuthentication folder at 27.92 GB
• ~/Library/Metadata/CoreSpotlight/Priority folder at 26.79 GB
• ~/Library/Caches at 1.85 GB

I do not believe “Optimize Storage” is turned on

Disk Writing:

• kernel_task had written 4.96 TB
• mds_stores had written 3.10 GB
• launchd had written 440.20 GB
• backupd had written 25.19 GB
• corespotlightd had written 47.46 GB

Steps to Fix (which is only temporary but not onerous)

12:59 PM —

• corespotlightd using >300% CPU
• Pages using 23.1% CPU with two small files open
• “Data written/sec” was typically sitting at around 180 MB

1:02 PM — trashed the ~/Library/Metadata/CoreSpotlight folder

1:04 PM — 

• corespotlightd down to 2.5%
• Pages down to <10%
• “Data written/sec” is typically staying <1 MB

1:22 PM — com.apple.podcast.SpotlightIndexExtension at 99.6% CPU

1:44 PM — at some point before this time, com.apple.podcast.SpotlightIndexExtension at 0% CPU

I would like to thank everyone who contributed to this listing, as it would have been impossible to resolve my sequoia/spotlight issue without all of your help. There appear to be two simple actions to eliminate the runaway spotlightd process.

• • Empty the contents of the ~/Library/Metadata/Corespotlight folder
  • Download the contents of the "pages" and "numbers" folders on iCloudDrive onto your computer

NOTE: It has only been two hours since the problem was resolved, but I am confident that it is gone.

I hope you find this useful.

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.

Interesting, so a solution involving iCloud backup would be:

• work on local copies of current Pages documents (example: in a Downloads folder, since this is usually not on iCloud)
• manual daily (or automatic / scheduled ) rsync of these files to Documents folder

--> I understand rsync would not trigger corespotlightd frenzied rage since it is an instant commitment, even if Pages is running on local and open documents?