Level 2

306 points

Continued corespotlightd process CPU overload issues

I am wondering if anyone has discovered any new ideas for stopping the corespotlightd process from hogging the CPU. According to Activity Monitor, the corespotlightd process often occupies more than 100% of the CPU load, sometimes spiking as high as 400% on my M2 Ultra Mac Studio. This problem has become so severe that it often pinwheels under normally non-intensive tasks. It can cause the video to flicker on my Studio Display. In one case it caused my Mac to kernel panic (crash).

I encountered this bug only after installing Sequoia 15.2, but having researched this issue extensively, I find that Mac users have identified it since at least macOS Ventura. So here are some solutions we don't need to hear again:

Reindexing Spotlight by adding and removing volumes in Spotlight Privacy. This provides relief only temporarily. Within hours the process is again grinding the Mac to a halt.

Killing the corespotlightd in Activity Monitor. Again, this is at best only a temporary solution as the process will reinstate itself.

A "clean" install of macOS. First of all, no such process really exists. The OS recovery process simply reinstalls a new copy of the System files. Nobody reports this as a fix. An internal drive wipe and reformat, and restore from Time Machine is also unlikely to help, as it simply returns your Mac to its previous state. If the corespotlightd problem results from a corrupted file, the problem will likely simply be recreated in your reinstall. "Nuke and pave" might solve the problem if it caused by a format or directory issue on your startup volume. This does not seem to be the case, but if anyone has permanently cured the problem by this method, please report it.

What we do need to hear is from anyone who has spent time with Apple Support on this issue and been provided with solutions that actually work, or has new ideas about what causes it. Feels like we're on our own here, since Apple seems to be stumped.

Posted on Dec 19, 2024 11:21 AM

Top-ranking reply

ericmurphysf

Level 2

307 points

Posted on Jan 31, 2025 8:44 AM

Okay, I have a new hypothesis as to what's going on here with corespotlightd. This process is one of at least four that are responsible for macOS's Spotlight functionality. The three others are mds, mdworker, and md_stores. I cribbed the following descriptions of these three processes from the HowToGeek website:

The two processes [mds and mdworker] are part of Spotlight, the macOS search tool. The first, mds, stands for metadata server. This process manages the index used to give you quick search results. The second, mdworker, stands for metadata server worker. This does the hard work of actually indexing your files to make that quick searching possible.

And for md_stores, from the TechNewsToday site:

Mds_stores is the core indexing process of the macOS. On normal days, it usually takes up a noticeable [sic, probably should be un-noticeable] amount of CPU. However, when you reinstall your OS or add new files/directories, your system will automatically start to reindex these new databases, which sees the mds_stores CPU usage skyrocket.

The macOS Spotlight feature makes use of two processes for indexing the system database; mds and mds_stores. The mds (Metadata Server) process is responsible for tracking and recording files and folders in your operating system. md_stores then compiles and manages these mds metadata, which Spotlight later uses for searching certain documents within your OS.

So it may be that corespotlightd is in fact an unwitting victim of other processes' having gone awry. On my two Intel systems, by three months after installing macOS 15.0, metadata associated with Spotlight located at ~/library/metadata had reached half a terabyte on both systems. It sounds like this data was actually written out by either mdworker, mds_stores, or both. And then, corespotlightd has to wade through these gigabytes upon gigabytes of metadata to actually produce search results, and as that task gets harder and harder with more and more metadata being produced, eventually Spotlight search results (which includes search and smart folders through Mail) degrade to the point of uselessness.

While I haven't managed to halt the rapid growth of metadata on these two Intel systems (Apple Silicon Macs still have the issue but to a much milder degree), simply deleting the metadata out of the ~/library/metadata/Corespotlight and ~/library/metadata/SpotlightKnowledgeEvents (while leaving the folders themselves intact) resulted in a near-immediate improvement in three areas: greatly reduced use of storage space; vastly improved search results; and much lower processor utilization by corespotlightd.

As noted, this metadata still continues to pile up (especially if I have a large (>5 MB) Pages file open). But if I have to empty out these two folders once every few weeks until Apple resolves the issue, that's not the end of the world).

View in context

346 replies

Jan 7, 2025 9:03 AM in response to Mitch Stone

Mitch Stone wrote:

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.

I should clarify what I did which did not resolve the Time Machine situation on one of the two Intel Macs:

Remove both backup drives from the backup rotation. This effectively disables Time Machine entirely since it has no drives to back up to.
Erase both backup drives via Disk Utility (APFS encrypted case insensitive in case that matters; I know Time Machine has a hard time backing up to HFS+ drives and has for a while).
Add the freshly-erased drives to the backup rotation.

In my experience, starting off in this condition (no existing Time Machine backups, freshly-erased drives), the initial backup should start immediately and back up a drive with say 650 GB of data on it in two or three hours. But since I first encountered this issue (endlessly "preparing" backups, kernel panics during or shortly after a backup), that has not been the case. Even an initial backup will be "preparing" for hours or even days, and even if it eventually finishes the initial backup the next backup will take even longer to "prepare."

This suggests to me that the problem is at least partially external to backupd, and given what I understand about the interactions between Time Machine and corespotlighd I suspect that the two are contending for system resources in some fashion. In any case, the benefits of backups to these two systems are outweighed by the inconvenience and hazard of repeated kernel panics.

SBML

Level 1

48 points

Jan 10, 2025 1:12 AM in response to SBML

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?

Mitch Stone Author

Level 2

306 points

Jan 10, 2025 10:47 AM in response to SBML

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?

Mitch Stone Author

Level 2

306 points

Jan 18, 2025 4:08 PM in response to RThomas

I can still recommend deleting the spotlight plist, as I described in one of my earlier posts. It doesn't seem to be a silver bullet, but the last time I did so the process calmed down and has remained manageable for several days now.

RThomas wrote:

Has anyone found ANYTHING that actually works?

Feb 9, 2025 6:24 PM in response to Mitch Stone

Mitch Stone wrote:

I don't think we know how large this folder is supposed to be, and I can attest to the fact that no process is taking over the CPU with the folder containing this much data.

I definitely don't know, but I think it's safe to assume that this folder (or these folders) definitely should not be more than a hundred GB. On my Intel Macs I didn't really start running into issues until they grew well in excess of that size.

But I think it's safe to assume that 500 GB is well beyond any rational size for metadata, on a system that otherwise only has about a terabyte of total storage in use. As I'd mentioned either here or on another thread specifically devoted to the metadata folders, at their maximum size these folders accounted for the majority of the data in my user folder.

But all that being said, one odd phenomenon I noticed was that when I cleared out these folders on my Intel Macs, doing so also seemed to resolve on my M-series Macs, even though I didn't remove any data from either of those two machines. I can only assume either (i) a happy coincidence; or (ii) that iCloud sync is somehow implicated, because even though my Mac Studio never had more than about 25 GB of metadata, I was having severe issues with 10- to 30-second long freezes, a kernel-panic or two, Time Machine issues, and overall poor performance that near-miraculously resolved after I'd deleted the metadata on the two Intel Macs I own.

I'm prepared to accept (i) might be true, but it's a pretty big coincidence if (ii) is not the case.

Feb 10, 2025 9:20 AM in response to PolyRod

PolyRod wrote:

From my perspective, Pages seems to fail when, after making an edit which might itself be trivial, I scroll. Pages disappears, then I get the windows asking if I want the report to go to Apple (and I always do allow that), and if I want to let Pages restart.

Time after time, Pages only loses the tiniest bit of editing. (Hats off to Apple on that score.) But it takes an annoying time to be able to get back to editing the document again.

I'm assuming you've tried the fix of deleting the Spotlight folders from your ~/library/metadata/ folder? If so, has the problem with Pages persisted even after doing so?

roysch53

Level 1

8 points

Feb 10, 2025 11:17 PM in response to PolyRod

I also relocated the contents of the folders named “NSFFileProtectionCompleteUntilFirstAuthentication” and “Priority,” deleting files from the original folders.

After restarting I did not open Pages for a couple of hours, on checking the above folders, they had not changed in size since restarting.

I opened two documents within Pages and within 30 minutes the directories had doubled in size.

I closed Pages and have just checked the directories again. After 12 hours, their sizes have not increased.

As somebody previously mentioned, the “store.db” file in both directories is exhibiting rapid growth but as to why, I don’t know

Mitch Stone Author

Level 2

306 points

Feb 12, 2025 9:57 AM in response to RThomas

This is an interesting observation. Shared Pages documents are always autosaved, so this might explain why we're experiencing greater issues with shared documents. I wonder if it might be helpful to turn off autosave. This requires flipping on the switch "ask to keep changes when closing documents" in Desktop & Dock Settings, which is off by default.

RThomas wrote:

I had been having problems before my upgrade to Sequoia. I am a heavy pages user with large docs. I began experiencing lag about a year before upgrading. As noted by another poster, the lag and freeze was most noticeable if I had made many edits, and was scrolling through the doc *without* hitting save. I was able to reduce the problems if I saved every minute or so while working.

Once I upgraded, the problems increased to pretty much any time I have a pages doc open - whether I've edited it recently or not, and no matter how little or big the file is. I've tried every solution listed here - most multiple times - they all work for a bit - sometimes for a longer, sometimes for shorter time period.

REALLY hoping they get this fixed soon - I use pages all the time, both while working with clients and as I'm preparing a manual for publication.

fcoteb

Level 1

18 points

Feb 16, 2025 6:47 AM in response to Mitch Stone

Glad I found this thread and hope everyone's efforts here will lead to a real fix in the next macOS update.

On my side: I use Pages extensively, albeit for relatively small files. I noticed the Pages app was taking 4 Gb of RAM, which is quite surprising. corespotlightd was indeed through the roof on CPU usage. This was heavily draining the battery, I was starting to get disappointed by Apple Silicon chip supposedly being superior here. I suspect things like that have been happening for a while but didn't find out why.

I am using:

M3 Pro Macbook Pro
18 Gb RAM
macOS 15.3.1

I have been noticing my hard drive is taking tens of Gb of space I am not aware of, in a few days. The folder Library/Metadata/Corespotlight is 40 Gb. I haven't touched it yet.

I disabled sharing Spotlight data with Apple.

Thanks everyone and I hope we'll get to the solution!

Feb 25, 2025 5:20 AM in response to Mitch Stone

For those who have been following the entire thread, I have some new data. It doesn't solve anything, but I thought I'd share.

For me the problem was replicable on 3 different machines, with these CPUs: M2 Pro, M3, Intel i7.

A week ago I upgraded my Mac mini to an M4, and on this machine I cannot replicate the problem. I've had 3 large (for me) Pages documents open for the past 2 days, and during that time the corespotlight folder has gotten smaller. It's currently under 2 gigs. At one point while writing intensively for many hours, the folder got as large as 5 gigs. But then I left the machine alone for a few hours (with Pages documents left open) and the folder got smaller.

On my other machines I never recall the folder getting smaller if Pages docs were open.

I should add that I DID use migration assistant to set this machine up, so it seems less likely that the "fix" was avoiding a problematic setting or preference file.

Mitch Stone Author

Level 2

306 points

Feb 25, 2025 11:48 AM in response to fronesis47

The inconsistency of this problem from day to day and Mac to Mac is crazy. I am presently not experiencing it on my M2 Ultra Studio. I never experienced it on my M1 MBA, even when opening the same Pages file on it as on the Studio. All this said, I am not convinced that preference files are not implicated, because the OS writes to some them, including the spotlight plist file. I suppose if this bug was a simple one Apple would have fixed it already.

fronesis47 wrote:

For those who have been following the entire thread, I have some new data. It doesn't solve anything, but I thought I'd share.

For me the problem was replicable on 3 different machines, with these CPUs: M2 Pro, M3, Intel i7.

A week ago I upgraded my Mac mini to an M4, and on this machine I cannot replicate the problem. I've had 3 large (for me) Pages documents open for the past 2 days, and during that time the corespotlight folder has gotten smaller. It's currently under 2 gigs. At one point while writing intensively for many hours, the folder got as large as 5 gigs. But then I left the machine alone for a few hours (with Pages documents left open) and the folder got smaller.

On my other machines I never recall the folder getting smaller if Pages docs were open.

I should add that I DID use migration assistant to set this machine up, so it seems less likely that the "fix" was avoiding a problematic setting or preference file.

drjz

Level 1

20 points

Feb 26, 2025 5:38 PM in response to Mitch Stone

Could you please define large in "large Pages document"?

I had trouble with Pages files 3-6 MB. Since then, I deleted the metadata several time, narrowed Spotlight's scope, eventually to zero, turned off AI, and even switched to Word for a while. Obviously rebooted. Finally the CPU settled down. Now, I have turned Spotlight back on, turned on AI, and gone back to using Pages with the same 3+ MB files, so far no CPU problems. Magic!? (The System data is ridiculously large at 100 GB, but that is not a problem compared with the lag from an over-busy CPU.)

Mar 6, 2025 1:06 AM in response to Mitch Stone

Tried playing around with a Microsoft Word file that was an exported Pages doc and even though the system is seemingly calm at rest, if I was to make the smallest edit possible (literally just pressing space bar) the response is actually somehow much worse than if it were just a normal Pages file. There is also a new issue of the read amount being absurdly high alongside the high write speed (when editing a Word doc). The response I get from a Pages file is more gradual and irrespective of what I do, the response I get from the Word doc is 100% reactive. Each and every edit no matter how small or simple will trigger a massive CPU and disk spike. If I do nothing it goes back to normal, however the disk read will continue to be elevated for around 8-10 seconds. This is a file that isn't even in the iCloud Pages folder, it's completely offline.

Additionally, losing hope at this point that this whole issue will be fixed in the next update but of course I don't know for sure. This app was an amazing switch and I did get several months of use out of it before this issue arose but I still wish I was able to go through all the phases of my project before this happened. I was willing to eat the disk write damage to the SSD cause at least I could pretend like it's not happening but the CPU spikes so high that it makes the fans kick and it's legitimately not something I can work around.

If for whatever reason you simply need to be able to read/present your document with all comments and chapters intact, export to Word. PDF allows comments but not as intuitively. I'm actually shocked how much information is perfectly retained in the Word doc.

Mitch Stone Author

Level 2

306 points

Apr 8, 2025 2:04 PM in response to ericmurphysf

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.

ericmurphysf wrote:

It's only been a few hours since I updated to 15.4, but so far the signs, at least on my Intel 27-inch iMac, are not encouraging. CoreSpotlightd isn't using much CPU time (7% on an 8-core system with hyperthreading turned on), but immediately after the update the (relocated) CoreSpotlight metadata was at around 2.6 GB (I'd deleted it all last night before the update to 15.4). It's now about two and a half hours later, and already metadata is up to 24.3 GB (with a large Pages file open). Before 15.4, after deleting metadata it would typically take closer to two days to get to 24 GB. If anything 15.4 seems to have worsened the problem of extremely rapid buildup of Spotlight metadata.

The next experiment will be to quit Pages for a while and see if metadata comes down in size. I've seen this many times on Apple Silicon systems, but the only way I've ever been able to reduce the size of Spotlight metadata on Intel systems is by manually deleting it.

Mitch Stone Author

Level 2

306 points

May 13, 2025 3:51 PM in response to fronesis47

I'd like to think it's exactly right, but unfortunately my own experience doesn't completely bear this out. For one, I had the issue without anywhere close to the massive growth of the metadata files others have found on their Macs. It has since become a non-issue for me without ever having deleted these files, even once.

The fix seemingly for me was Finder duplication of the large, heavily edited Pages document that apparently caused the process to go berserk. Since then, no problem. At all. The document has since been substantially edited. I can leave it open for hours, days. No problems. At all.

So to me this is a cause and effect issue we are never going to fully explain or understand. Only Apple can do that, and I hope they do. In the meantime, we as users need to do whatever works for our situations.

Continued corespotlightd process CPU overload issues