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 Dec 31, 2024 11:01 PM

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.

305 replies

May 19, 2025 01:39 PM in response to KWiPod

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.

May 19, 2025 03:47 PM in response to ericmurphysf

ericmurphysf wrote:

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

By now you know what I think about monitoring the metadata folder and assuming that, if it gets large, then you have a problem. With this observation perhaps you more fully understand my point. We don't know the cause and effect relationship, so I feel it is better to focus on the effect, and keep in mind that if you hadn't experienced the system performance issues you never would have concerned yourself with the size of the metadata files, or looked at Activity Monitor for running processes. This would all be happening in the background.


So here's a question: Have you ever tried turning Spotlight off, effectively, by exempting all volumes from indexing? What would happen to the size of metadata files then, I wonder?

May 26, 2025 02:13 AM in response to Mitch Stone

I’ve been troubleshooting a recurring issue with corespotlightd (CPS) spiking CPU usage — often over 200% — when using Pages. It renders my otherwise fast, brand-new M4 MacBook Air nearly unusable.


I’m trying to determine if this is:


• Processor or Mac model specific


• Related specifically to iCloud Drive


1. Is CPS Processor or Mac-Specific?

I never experienced this issue on my MacBook Pro M1 Max, running Sequoia or earlier versions (Monterey, Ventura, Sonoma). Since March 13, 2025, I’ve used my M4 MacBook Air for all my daily writing in Pages — and this is where CPS began.


Has anyone else seen corespotlightd spikes on an M1 Max MacBook Pro? That would help rule out a hardware-specific trigger.


2. Is CPS iCloud Drive Dependent?

In my experience: yes.


Here’s what I did:


• My last major CPS spike occurred even after quitting Pages for over two days.


• I reinstalled Sequoia 15.5, and after file indexing completed, CPS calmed down.


• Before reopening Pages, I duplicated all my current Pages documents and placed them in a local folder:


Macintosh HD > Users > [MyName] > InProgressNoCloud


• iCloud Drive is still active, with Optimize Mac Storage ON.


For three days now:


• I’ve been editing these local Pages files, keeping them open alongside other apps like Mail, Messages, and large Numbers spreadsheets (still stored in iCloud).


• There have been no corespotlightd spikes.


• In fact, the corespotlightd process doesn’t appear at all in Activity Monitor when working outside of iCloud.


• In contrast, with Pages files stored in iCloud/Documents or iCloud/Desktop, corespotlightd is always active.


This suggests a strong link between Pages auto-saving to iCloud Drive and Spotlight re-indexing, which seems to trigger runaway CPS activity.


A Temporary Solution

So far, keeping active Pages files out of iCloud Drive and stored locally appears to solve the problem.


But this isn’t ideal:


• I rely on my 2TB iCloud Drive to sync and protect files — I don’t want to back up Pages manually.


• I prefer not to split screen space with Activity Monitor just to monitor CPU usage.


• Most importantly, I want confidence that my M4 MBA won’t grind to a halt mid-session due to runaway corespotlightd.


As a side note: I do use SuperDuper to back up my MBP (for Logic Pro files, which must be stored locally), but for documents, iCloud Drive has been excellent — until this. Another side note: I've had two other process spike issues and BOTH were triggered by Pages: mdworker in 2013 and AppleSpell in 2019.


Next Steps

I’ll continue testing my temporary solution and will update this post immediately if CPS returns.


Jun 3, 2025 12:15 PM in response to PolyRod

The wide variation of experience with this bug is vexing. In my case I was easily able to verify that iCloud was definitely not a factor. Others find evidence that it is, for them. This brings me back to my theory that it is document-specific and that moving or duplicating the document can mitigate it, at least in some cases.


Maybe the forthcoming macOS update (which we are hearing will be called Tahoe) will finally fix it for everyone. We can hope, at least.

Jun 19, 2025 11:24 AM in response to Mitch Stone

After a couple of minor OS updates, this issue is still plaguing my M3 Pro MacBook Pro. Fingers crossed for the final update to macOS Sequoia, or the first of Tahoe.


And here I was thinking that Apple's own apps would work seamlessly in its own ecosystem.


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

Jul 4, 2025 01:39 PM in response to revpilot

revpilot wrote:

Thank you Eric. I have gone to that and there is no folder listed as metadata. ** I looking in the wrong place? If I **, I would appreciate you telling me how to find this. I have gone to Settings, clicked Spotlight, Privacy and told it to rebuild, and have not have major success with that. I did this when an Apple Support person told me to this. Any help is greatly appreciated.

The metadata folder I'm referring to is in the user library folder. To get to your user library folder, go to the "Go" menu in the Finder. If you don't see the Library in the "Go" menu, hold down the Option key on the keyboard. Scroll down to the Metadata folder inside the Library folder. Inside, among a few other folders, you will find a folder titled "CoreSpotlight."


Apple recommends that you delete the contents of the CoreSpotlight folder, but not the folder itself. That's how I've always done it. Other users have deleted the folder itself, apparently without ill effects. Either way, macOS will recreate the folder (if you delete that) or its contents (if you just delete the contents). You might need to wait a while for Spotlight searches to return usable results after deleting, so I usually delete the metadata when I know I won't be using the computer for a while, either right before I leave work or before I retire for the evening.


Note that this is not a one-time fix. I typically delete this metadata when it gets above 40 GB, which depending on who knows what other factors can take anywhere from weeks, or months, to less than twelve hours. In my

experience having a large Pages file open reduces the time before I have to delete the metadata again.

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.

Jul 5, 2025 01:24 AM in response to revpilot

I totally understand your frustration regarding Pages corespotlightd spiking. The lack of response from Apple is unusual: 


Back in 2013 and again in 2019, Pages was causing process spiking for mdworker and AppleSpell respectively. 


In both cases, I reported issues via Apple’s Feedback Web pages and was contacted by Apple, asked to install profiles, emailed the files back to Apple, and the issues were fixed. 


I posted a temporary Pages corespotlightd solution a month ago - do not use Pages with iCloud Drive - and it it is still effective. In case you have not seen that post:


Move any extant Pages files you want to open on your local SSD (i.e. not in iCloud Drive) before you open them.  When you create a new Pages file, immediately save it to your local SSD.


This works because if your Pages files lives in iCloud Drive, Pages triggers  corespotlightd   . . . which then spikes to > 200% and slows down your Mac  to the point of un-useability even after Pages is quit. (When corespotlightd is spiking, the only way to stop it, is to reinstall MacOS.)

Dec 29, 2024 11:11 AM in response to Mitch Stone

"A "clean" install of macOS. First of all, no such process really exists."


Agreed in principle. Apple does offer Disk Utility on its recovery tool to erase the entire data drive, or the entire hard drive, and use internet recovery to restore the OS that came with the Mac, or in recovery, the last installed OS. Simple recovery keeps a partition with just the necessary tools to install the OS.


Use macOS Recovery on an Intel-based Mac - Apple Support - command-option-shift-R for Intel Macs.

Use macOS Recovery on a Mac with Apple silicon - Apple Support (these are Macs that were new starting November 2020 and later)


Either will give you a closer approximation of whether or not the issue is due to the storage issues, or issues with the computer. The Apple Hardware Diagnostics if they find something wrong could indicate something is wrong with hardware.



Feb 9, 2025 02:59 PM in response to Mitch Stone

Just to provide an update and add more context to the discussion:

I'm no longer experiencing any hiccups, mini-freezes, or beachballing. While I’m currently writing my thesis in Pages, my issue might not have been directly related to the app after all.


A few key points:

  • I'm working entirely with iCloud files (Pages), and while corespotlightd still spikes occasionally, it does so as expected and without causing any slowdowns.
  • kernel_task and corespotlightd are no longer consuming excessive CPU resources.


The turning point seemed to be when I deleted my 50GB ~/Library/Caches folder. After restarting, the system automatically rebuilt the Cache folder, but it has remained steady at around 600MB ever since.



Additionally, I reset my Spotlight index, first via System Settings and then using Terminal with sudo commands to wipe and rebuild it. After indexing completed (which took around an hour or so), my ~/Library/Metadata/Corespotlight folder settled at around 30GB. Despite its size, my system is now running as smoothly and responsively as I expect it to be.



I personally can't work without spotlight anymore and try to index most of the files on my system to have an extremely fast access via CMD+Space. What I'm trying to say is: although my Spotlight folder currently seems to be this big I'm not seeing any performance issues on my end.


Things too keep in mind about my situation:

  • I'm not working on super big Pages files with file sizes over dozens of MBs
  • I'm not using storage optimization via "Store in iCloud" in the storage settings
  • I have updated from 15.2 to 15.3 with obviously very big Cache and Indexes (~/Library/Caches & ~/Library/Metadata/Corespotlight basically never emptied since I own this M1 MacBook from 2021 onwards)

Jan 7, 2025 09: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.

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

Mitch Stone wrote:


Having tried this myself, I must report a non-confirmation. I opened a large Pages file and watched the Corespotlight folder file size. It started out at 60.35 GB and remained exactly this size after a half hour, even though the process showed as being very active (100+ percent) for part of this time. I don't doubt that deleting it has a temporary effect but it's also clear that this folder growing in size cannot be triggered predictably by opening a Pages file.

This is helpful. Some key questions:

  1. When you say "the process showed as being very active" do you mean corespotlightd? For the record, when I repeatedly watch the corespotlight folder grow (with a Pages file open), it is NOT associated with the corespotlightd process. To the contrary, it's mdworker and mdstores that are writing all the data to that folder.
  2. Do you have optimize iCloud storage turned ON, on your machine?


On my Mac with optimize OFF, the corespotlight folder always grows with a Pages file open. But on my Mac without optimize storage ON, I do not see the growth as consistently.

Feb 12, 2025 10:13 AM in response to CaptainJoy

CaptainJoy wrote:

Feb 11 6:28 PM — trashed the contents• of ~/Library/Metadata/CoreSpotlight and ~/Library/Metadata/CoreSpotlight/SpotlightKnowledgeEvents which immediately resulted in:
corespotlightd down to <25%
• Disk writing no longer happening constantly
• Every indication this has "fixed" my problems.

This was the 2nd time I've had to "fix" my sluggish, cursor freezing, beach-ball generating 2024 M4 Mac Mini running Sequoia 15.3. I put "fix" in quotes because this is only a temporary solution. The last time I had to implement this "fix" was 3 February, so it seems to last about a week for me. I was no longer keeping Pages documents open unless actively using them ; I think I'll go back to leaving my planner Pages document open like I used to and see how much it cuts down the time before my next "fix".

PS AshkaTheMoltenFury is an hilarious handle.

I'm not certain how significant this is, but I have yet to need to remove the above-referenced folders on either of the two Apple Silicon systems I own: a M1 Ultra Mac Studio or an M2 Max MBP. Neither system's Spotlight metadata folders have ever exceeded 50 GB, and I have not seen serious performance degradations* on either one.


But I've had to remove Spotlight metadata twice each from my two Intel systems, a 27-inch iMac and an iMac Pro. I deleted this data once on each system when it had more than 500 GB of metadata in these folders, and then once again on both systems when metadata exceeded 100 GB a week or so later.


In all four cases, I saw immediate performance improvements, especially in Spotlight searches (which had been essentially inoperative once metadata exceeded about 250 GB), and Time Machine backups never starting let alone completing. And so far literally no downsides whatsoever to removing this data.

_______________________________

  • I did for a short time see issues on the Mac Studio with 10-30-second freezes, especially during video playback, one or two of what looked like kernel panics (the system simply shut down entirely the first time, and then shut down and restarted the second time), along with some oddities with Time Machine. Either coincidentally or not, once I removed the excess metadata from the two Intel machines, these problems seemed to resolve on the Mac Studio via unknown and unguessable mechanisms. I should probably note that all four of these systems are under the same iCloud account.

Feb 16, 2025 06: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!

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.