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

Reply
Question marked as Top-ranking reply

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).


328 replies

Sep 2, 2025 1:03 PM in response to David MacVicar

[I have iMac 27-in Retina 5K display. 3.8GHz, 8-core, 10th gen, Intel Core i7]


Two points that work for me.  NB: This CPU overload issue seems individualized for different folks/devices.


1. Delete Metadata – I am conservative about what I delete, because I don't know what I'm doing.  I delete only the files which seem to accumulate large data in Metadata.  [Highlite file/folder >Right click > "Info"].  I find only two folders with large data:  CoreSpotlight and one of its larger sub-files SpotlightKnowledgeEvents.  Other files seem negligible in size, and I can ignore them.  They don't seem to change much, ever, or at all.


I highlight and delete the contents of CoreSpotlight all the way "down" to SpotlightKnowledgeEvents.  Then, I delete the contents of SpotlightKnowledgeEvents. Those two folder contain all the accumulated data under Metadata that causes issues.


When I go to my Metadata folder*, I open Metadata folder and find other files and folders (number depends on time lapsed since last delete). Finder > Go > Press "Option" to reveal secret folder "Library" > Metadata >


2. "Duplicate" problematic large Pages files. – This seems to eliminate metadata on the duplicated file, and it's only the large Pages files that seem problematic.  I have one very large file that I work with often.  If I duplicate as needed, my CPU overload issues are not an issue.


I can go days and days with no growth in metadata.  The issue seems resolved… until it's not.  Issue seems revived when I open a new large Pages file, which I've not duplicated.  So, I duplicate that file, and issue goes away.


I rename the duplicated file ending with the date copied, so I can track that.  I send the old file to trash. 


I don't like having to do any of the above, but it seems to work for me, eliminating CPU overload issues.  I'm hoping Apple some day makes the software fix for this issue, because it's very frustrating.  I hope this group can pressure Apple.  If/when I have sufficient time/energy, I will go on social media and creatively whine so loud, Apple might wish they have fixed this issue.  Until then, the above bandage works.


I also check in System Settings (Apple logo top right > System Settings > Storage, which opens "System Data" at bottom.  I get a larger figure, like 132.78 GB, which changes after a 1/2 minute to a smaller figure, like 102.34 GB.  This provides less detailed info, but it's a good match with "Library" folder, and I find it satisfying, when I delete Metadata files and folders, to watch Trash line appear, and then disappear when I empty trash.  I track that daily, so I can note when/whether the Metadata folder are large enough to need deletion.


Dec 29, 2024 4:20 AM in response to Mitch Stone

Was trying to solve this issue and happened to notice the setting below. Help Apple Improve Search in the Spotlight options.



I don't have any recollection of letting Apple improve search! Disabled. And found spotlightcored dropped to effectively zero CPU!


No idea if this will remain the case. But seems worth a go if it is selected on your machine.

Dec 31, 2024 11:38 PM in response to MgS_2012

MgS_2012 wrote:

I have a follow-up call with Apple Support tomorrow morning. (I started squawking about this with them last week when the problem resurfaced after a re-install of the OS).

Correlation? It seems concerningly probable that something to do with Apple Intelligence integration is related to this issue.

A connection to AI is a reasonable conjecture, given the timing of this problem for most of us, but I have seen reports of this issue going back several years. I am also not seeing it on my MBA, which is fully updated and with the AI features enabled on it as well. I'm not surprised that an OS reinstall did not help, for reasons I've previously described. Many will be interested in a report on your call with Apple Support.


Meanwhile, another observation: the spikes in CPU usage as shown in Activity Monitor seem to be in User rather than System. This suggests creating a new user on your Mac and seeing if it inherits the problem. My theory is that it won't, because the issue is with a corrupted plist in the user directory.

Jan 1, 2025 9:11 AM in response to Rollwagen

It's almost certainly a user issue, as the CPU load graph shows. I'm sorry Apple put you through a reinstall. A world of hurt for no benefit. Support should know better. If you can get your problem escalated to Level II Support you can talk to someone more knowledgeable who won't take the blunderbuss approach. Ultimately this needs to be handed over to Engineering.


Rollwagen wrote:

Thanks for your posts! I have large Pages files on my M2 MB Air and Apple Intelligence turned on. Editing those docs is when I first noticed the problem that eventually led me to corespotlightd high CPU usage. I’m wondering if Writing Tools in Apple Intelligence is the culprit. I talked with Apple Support yesterday (NYE) and made it to the point in troubleshooting where we identified it as a User issue and not system wide. We progressed to a system re-install, which you already know doesn’t work. I’ll talk with Support again tomorrow, but in the meantime, I’ve turned off Apple Intelligence on my Mac to see if it will also calm down


Jan 3, 2025 9:02 AM in response to Mitch Stone

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

May 19, 2025 9:02 AM in response to KWiPod

You are the first (to my recollection) to report that any file type other than Pages triggers an out-of-control process. When I was having this problem, it persisted for 10-15 minutes after opening the Pages file, and continued for that time period whether the file remained open or not. So this may be what you are seeing. This does seem to be a recursive error. The process peaking had a "beat" to it of around five seconds.


I'm interested in the results of your experiment keeping these working files in a separate folder excluded from Spotlight indexing. You might also try making a Finder copy of a document that causes the problem and working with it. One theory is the document version history saved by Pages is a culprit. It made a difference for me, anyway.


Sorry you went through the agony of a system reinstall. I'm surprised it helped even temporarily.


KWiPod wrote:

Hi Mitch. I always assumed the issue was related to Pages. But this latest spike persisted for hours even with all apps closed and my SSD and iCloud removed from indexing. [ChatGPT suggested that a corespotlightd spike of >200% (which is happening as I type this accompanied by the SBBoD!) is likely is an indexing loop or bad database, and advised deleting the index in Terminal with sudo mdutil -E /. 


Jul 5, 2025 12:50 AM in response to Mitch Stone

There seem to be some new followers of this thread.


Again, my very simple and working solution is to work on Pages document saved in non-iCloud folders (Downloads for example).


Then, when you are done, you can copy the document in Documents folder or similar.


When you have to edit, do the reverse: copy in Downloads, open that document, save, and then copy back into Documents.

Jan 3, 2025 9:31 AM in response to Rollwagen

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


Jan 6, 2025 11:36 PM in response to ericmurphysf

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.


Feb 9, 2025 2:03 PM in response to Mitch Stone

Mitch Stone wrote:


Earlier in this discussion it was established that iCloud is not the culprit. Files that will trigger the problem will do so whether they are stored locally or in iCloud. I meant corespotlightd because this the process I see as being hyperactive when the CPU is overloaded. Either way I have had this large Pages file open for over an hour now and the file has not grown at all. Unfortunately all of the theories we've come up with so far are incomplete or flawed. They only seem to work for some users some of the time.

I realize iCloud is not the cause per se (because the problem has been reproduced with Pages files that are not on iCloud Drive). I'm curious about exploring the possibility that the problem is worse without the optimize function on. It seems to me that with my two machines, there's just much slower growth of the folder on the machine with optimize on.


I'll also add: I'm not sure your case completely disproves the general thesis. 60Gb is a really large metadata file. It's already at the point that corespotlightd is taking over the CPU. So by this point it doesn't really matter that the folder has stopped (or significantly) slowed its growth; it's already a problem. And I guess I have to assume that the folder got that big for the same reasons as everyone else. If you could delete your folder, and then open a pages file and have the folder not grow – that would be a totally different data point.


Now that I've been deleting my metadata folder (as an experiment) I have absolutely zero issues with corespotlightd. If the corespotlight folder is smaller than 10Gb I find I never have any slowdowns at all.

Feb 10, 2025 1:04 PM in response to PolyRod

PolyRod wrote:

And that just might correspond to my Pages issues. The documents which have always seemed to be the most sensitive to issues have significant and dense Tables of Contents.

Interesting about the Table of Contents in Pages files. I keep a daily journal which by the end of the year can run to well over a thousand pages (I'm long-winded to put it mildly). These journals have 13 ToCs: the main one with entries for each month, and then each month has a section ToC entry for each day in the month.


This issue became particularly severe towards the middle of December of last year when my Pages journal file was over a thousand pages long and had something like 350 ToC entries. The problem persisted even after I stopped editing, or even opening, this journal file and started a new one for the new year. But I think what happens is once the metadata gets to a certain size (maybe 100 GB or more), the problem starts to snowball, with increasingly large amounts of metadata being saved and corespotlightd spiking as it tries to trudge through hundreds of gigabytes of metadata.


I've had very good luck with just deleting all this metadata and letting Spotlight rebuild it. It doesn't cure the problem permanently, but so long as I don't let these folders get too large, my systems are gratifyingly free of the stalls, system crashes, and even Time Machine issues I'd been having previously.

Feb 26, 2025 7:47 AM in response to Zenith

Zenith wrote:

Next stop on the troubleshooting train: exclude ~/Library/Metadata from spotlight. Why would we need spotlight to index that anyway for routine operation?

I think you're right about what is causing Spotlight metadata to balloon (and have been discussing the matter with Apple support for over a month; currently I'm waiting for a response from engineering).


That said, I tried your troubleshooting step noted above, with negative results: Spotlight metadata continued to grow, and much more quickly if Pages is running with a document open. The only "fix" for this issue I've found to work so far is to regularly delete Spotlight metadata out of the ~/library folder. I'm a pretty heavy user of Pages, so I have to do this about every ten days, by which time metadata has usually exceeded 60 GB.

Feb 28, 2025 11:06 AM in response to ericmurphysf

An update on my status. Similar problems to everyone else. I too have large pages files, several machines, and iCloud file storage and sync. Deleted spotlight metadata a few times. Helped for a while, then the problems returned -- large metadata folders, high CPU load, and that weird rhythmic spiking of the CPU usage.


This week, the mouse (old Logitech with usb dongle for bluetooth) lag was significant across several apps, beginning with pages. Thought my mouse batteries were the problem. Changed batteries. Didn't work. Changed mice - went through all 3 of my usb dongle-bluetooth Logitech mice, and then switched to my bluetooth only laptop mouse. The problems went away.


Got new bluetooth only mice, and also dumped the metadata again. CPU load has been low and steady, Corespotlight metadata folders have stayed under 10 GB for a week!


Yet another weird data point.

Continued corespotlightd process CPU overload issues

Welcome to Apple Support Community
A forum where Apple customers help each other with their products. Get started with your Apple Account.