Continued corespotlightd process CPU overload issues

As of Friday, May 15, 2025 the bloated ~/Library/Metadata/Corespotlight folder is no longer being bloated. Hooray. All is right in the world... Of my Mac mini. Checked my settings and I have auto download of updates, so it looks like that did it. Good job Apple.

Yesterday, I again deleted the contents of the CoreSpotlight metadata - on both M1 MBP and M4 mini. (Both bang up to date on Sequoia 15.5)

Despite using Pages and Numbers (the two problem apps for me) - the contents have remained modest for about 24 hours so far. Currently well under 2GB on both machines and not obviously growing.

Can I afford to raise some optimism? Or will it suddenly revert to excess growth of CoreSpotlight and mixed beachball and non-beachball freezes? I've been somewhere like this before...

And . . . after working in Numbers, Keynote, Safari, Notes, Mail and Messages … I dared to open a Pages document (that is excluded from Spotlight as I noted in my last post)  . . . and  . . .  I’m back to SBBoD with corespotlight at 168%. 

I’ve closed Pages, but the corespotlight spike-crisis has persisted for 15 mins with the kernal_task process also spiking just to provide extra spike-spice. 

So, my situation is, in order do Word Processing on my new M4 MacBook Air, I must:

• export my Pages files to Microsoft Word, while battling with the SBBoD (and Command Tabbing between apps freezing the screen for several seconds each time);
• Reinstall MacOS Sequoia (again) to kill this corespotlight spiky-crisis;
• Work in Microsoft Word until I feel confident Pages is safe. (Assuming Apple choose to fix the issue. And it is, after all, an issue with an Apple - not a third-party - App!)

BTW (again): I have just remembered that the Pages team also reached out to me in 2019 when I had a document that caused many issues related to the AppleSpell process. (My Pages diary document includes pasted material from emails [from Mail] and rich texts [from Messages]. AppleSpell did not play nicely with this activity. Again, as in 2013, Apple reached out to me and I installed a profile, etc. … and  the issue was solved. 

KWiPod wrote:

I’ve had a few comments about other apps: in my experience, it is only Pages that causes the corespotlightd spike crisis. And It’s persistent and repeatable• : 

My Mac runs normally running all my other apps.

Unfortunately, I think the situation is more complicated than that, and in my experience (with four different Macs, two Intel and two AS), results will change not just from one Mac to another but from the same Mac at different points in time.

Case in point: I had deleted Corespotlight metadata yesterday morning, with Pages not running. Normally I'd expect maybe a few GB of data to accumulate over the next few hours. But six hours later, the Corespotlight folder had grown to thirty-five gigabytes while the system was idling (I wasn't even in the house during that time). I once again deleted metadata yesterday evening, and with Pages again not running, I watched the Corespotlight folder grow to more than a gigabyte in less than five minutes. Fortunately that growth eventually slowed, but this morning, again with the computer seeing almost no use, metadata had once again increased to almost 30 GB.

That said, I have not seen either corespotlightd or the metadata processes (mdworker, mds_stores, etc.) using excessive CPU time (these days, at least for me, contactsd seems to me a major consumer of CPU time).

So while I remain pretty sure that Pages is implicated in the absurd growth of metadata, even not having it run at all is no guarantee of anything. The only thing I know for certain that works is that if I keep Spotlight metadata below 40 GB or so, my systems seem to run pretty smoothly.

Hi I've been this problem huge time since March, when I did start editing a very large pages' file.

I discovered this bug report page just recently, I previously mitigated it by loop script killing corespotlight (lol) while using pages.

I updated to OS to 15.5 and will monitor the folder size with

while true; do clear; du -sh ~/Library/Metadata/CoreSpotlight; sleep 60; done

It seems strange to me that we do not have an official acknowledgment or statement from Apple about this issue, am I missing something?

Does anyone with this issue not use Time Machine for backups?

While everything seems to be working well on my M1 MBP at the moment, the spotlight folder grew substantially after I had done a TM backup. From under 2 GB to almost 10 GB. Could spotlight indexing of TM backups be contributing to the size of the spotlight metadata?

I simply plug in a 1 TB external drive every so often and did that between checking the spotlight folder yesterday at 16:55 and this morning at 08:00.

In other words, if we clear the spotlight folder we see reasonable space usage until we run a TM backup. At which point it grows enormously. This might explain my observation that everything works OK for hours, even days, after clearing spotlight. Then suddenly the space usage rises enormously.

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?

Having had a period of relatively little impact, I've had terrible issues this morning. Using Numbers seems to be the biggest issue. A sheet of 448 kb and pretty simple except for being a pivot table.

M4 mini freezing repeatedly. And Spotlight folder bigger than ever.

I did have a Pages file opened - but even closing that - and idle Excel and Word instances - did not fix the issue. Only closing Numbers - and waiting - got me out of the mire.

This ridiculous size is making my drive look rather full.

PolyRod wrote:

A few days ago, Apple contacted me and asked for some diagnostics - which I sent and got a thanks.

I think that the issue is having less impact than at one point. But still get beachballs regularly. And just maybe I automatically close Pages and Numbers when I'm not actively using them - sort-of habituated into doing so! Thus avoiding things like having the same documents open on two machines.

This has been my experience for the most part. I have not seen serious performance issues with corespotlight processes interacting with Pages in quite some time (other than if I happen to leave Pages open on my M2 MBP, battery life suffers dramatically, even with the lid closed).

But it appears that if anything, the macOS 15.6.1 update has exacerbated the issue of rapidly-accumulating corespotlight metadata. I ran the update last week, and over the weekend, with both Pages and Numbers closed on my 2020 27-inch iMac, metadata piled up to well over 100 GB, the highest it's been in more than six months. I deleted it Monday morning, and by this morning (Tuesday), it was back up over 60 GB. Two and a half hours later, it was already up to almost 17 GB. That suggests I may have to delete metadata once more before I leave for the day.

That said, I'm not seeing much in the way of performance degradation. The CPU load is roughly 20%, and no spotlight processes appear to be in the top 10 for CPU use.

So, 'xxxx' i.e. MacOS Tahoe 26 is now out, so we can finally discuss it and I have installed it on my M4 MacBook Air.

As noted in my earlier posts, due to the corespotlightd process massive spike issue (with MacOS Sequoia and Pages 14.4), I’ve been opening old (and saving new) Pages files from(to) my local SSD. This is because for me, it's working with Pages documents in iCloud Drive that triggers the corespotlightd beach-balling crisis on my Mac.

My current Pages-based projects are too important for me to risk retuning to iCloud Drive in Tahoe.

Are there any brave folk out there who can offer any feedback on Pages with iCloud Drive in Tahoe?

I'm also curious if Tahoe resolves this issue. I haven't had this issue since I stopped using Pages months ago, but it sure would be nice to be able to use Pages again.

Hmmm - okay - I'm seeing the same behaviour, but instead of with large documents (mine are sizeable, but not huge), but with _NUMBER_ of documents being accessed.

In my context, I have 8-10 documents open at any one moment (all on iCloud), and an additional 5-20 PDFs opened in Preview.

I did a reinstall of MacOS about 2 weeks ago after this problem cascaded into spontaneous crash-and-restarts even while the machine was otherwise idle (all documents closed), and I was in the midst of a lengthy video call when it decided to crash. (I also saw multiple spontaneous reboots happening overnight when the machine was otherwise idle).

Regarding re-install of MacOS, when I ran Disk Utility from Recovery Mode, it identified a ton of mismatch counts and other filesystem errors that it was unable to repair. At that point, I decided to do a nuke-and-pave, with the computer behaving itself until today when I see corespotlightd chewing CPU like candy again. (It wasn't even appearing in the list for top prior to today).

If the suspicions mentioned above are true, then this appears to be an indexing problem with the interaction between Spotlight and iCloud. (I'm reaching here, but iCloud indexing looks like a common denominator)

%CPU is a bit of an odd duck in today's world of multi-core processors. It made more sense when we were doing things on single-core architectures like the VAX (yes, I'm that old). Back then a process chewing large amounts of CPU was pretty obvious. In a multi-core architecture, a process can simply get allocated to a different core when it gets switched out, resulting in the appearance of using "more than 100%" of a CPU. (The core allocation logic is opaque to most human beings - and I'm not exactly sure what the kernel / hardware interaction looks like there - it's been a few moons since I did any amount of kernel work)

Top in its default form is a bit aggressive, resampling every second. I tend to use the command "top -o CPU -s 5" to make it a little less hungry.