corespotlightd high CPU on Mac: read-only diagnosis before you delete anything

If corespotlightd is using a lot of CPU and the Mac is hot, do not start by deleting Spotlight’s files. Take one process sample, one short top -l sample, and mdutil -s /. Those three do not turn indexing off and do not erase the index. The only incident written up here saw corespotlightd and mds stay busy for hours, with mdutil -s still saying Indexing enabled, and a live log stream flooded by CoreDuet messages. That writeup does not record a macOS version, and it does not show a measured CPU number after any delete.

The longer notes from that day are in Chinese: corespotlightd CPU 高占用、Mac 发烫：先只读排查，别急着删库. This page is the order to follow before you touch anything. Self-hosting notes are a different path: start here.

What these notes actually recorded

On 2025-07-30 the machine was hot and corespotlightd was busy. sudo asitop showed the performance cores at 100% for a long stretch. top -o cpu, left open for hours, kept showing corespotlightd high. Together with mds, the reading was about 180%–200% CPU for several hours. That figure is one session in top. It is not a benchmark for every Mac.

mdutil -s / kept printing Indexing enabled for those hours. Those words only mean the volume’s index is switched on. They do not say a scan is still running, and they do not say it has finished. Treating them as “the rebuild is not done” was a guess, and it was not checked with a second command.

A live log command was also run:

log stream --predicate 'subsystem == "com.apple.Spotlight" or process == "corespotlightd" or process == "mds"' --style compact

The terminal filled with mds lines of CoreDuet: ClientContext objectForContextualKeyPath:. That command does not change the database. It is a poor first step because it does not stop.

mds is the metadata server, the Spotlight service that handles metadata. corespotlightd is the helper next to it, and it was the process using the CPU. CoreDuet is the subsystem that stores usage patterns so the system can guess when to index and how to schedule power and background work. That is an explanation of the log lines, not a check of the database files.

People also search for mds_stores and mdworker high CPU. These notes do not say what those two processes did on that Mac. They only name corespotlightd and mds.

Read-only checks, in this order

None of these turn Spotlight off, delete a database, or rebuild the index. Stop when you have the answers they can give. mdutil -s, interactive top -o cpu, and log stream are the commands that were actually used. The others are the same kind of read, and they were not re-run for this page.

1. Is the process there?

ps -axo pid,pcpu,etime,command | grep -E '[c]orespotlightd|[m]ds '

This only reads the process table: whether corespotlightd and mds exist, a rough %cpu, and how long they have been running. The brackets keep grep from matching itself.

2. Two samples, then quit

The original session used top -o cpu and left it open for hours. A sample that exits is enough:

top -l 2 -n 15 -o cpu

-l 2 takes two passes and stops. If corespotlightd is near the top in both, it looks more like a sustained load than a one-second spike. It does not change the index.

3. Ask whether indexing is on

mdutil -s /

Query only. Do not add -E, and do not add -i off. -E erases the index. -i off turns indexing off. The output in the notes was Indexing enabled. That sentence does not say how far a scan has gone.

4. Read logs that are already on disk

Prefer a short window over a live stream:

log show --last 10m --predicate 'subsystem == "com.apple.Spotlight" OR process == "corespotlightd" OR process == "mds"' --style compact

If the command says it cannot read the log, sudo here is only permission to read. It does not repair Spotlight. This page did not re-run log show, so it cannot promise the same CoreDuet flood you would have seen from log stream that day.

5. Optional: watch file calls, briefly

fs_usage was not part of the original notes, and it has not been retested here. It watches file calls. It does not edit the index or delete a database:

sudo fs_usage -w -f filesys corespotlightd

Stop it with Ctrl-C after a few seconds. The output is dense, and the command itself uses CPU. Do not leave it running for hours on a machine that is already hot. It can show paths the process touches. It cannot tell you which directory to delete.

Indexing, or just spinning

If ps and top -l keep corespotlightd or mds near the top, and mdutil -s / only says the index is enabled, you know two things: the switch is on, and those processes were busy. Busy can be a normal rebuild. It can also be the loop the log showed, where mds keeps asking CoreDuet for context and does not finish the request. The read-only commands do not separate those cases, and they do not prove that files under /private/var/db/CoreDuet/ are damaged.

Stopping here is a valid result.

What not to do

Do not run sudo rm -rf /.Spotlight-V100, or the same kind of hand delete of a Spotlight folder. These notes never used that command. A raw rm -rf does not go through Spotlight’s own tool. A wrong path, especially one that starts higher up at /, deletes something else. The notes also never checked that /.Spotlight-V100 was the live index on that Mac, so deleting a guessed path is not a diagnosis.

Do not start with sudo mdutil -E / either. That was run before mdutil -s in the original session. It erases the volume’s current Spotlight index and starts a rebuild. Your files stay, but search is incomplete until the rebuild finishes, and CPU can go up during the rebuild instead of down. There is no command that puts the old index back. Running -E again only erases it again.

Do not delete CoreDuet to “fix” the CPU:

sudo rm -rf /private/var/db/CoreDuet/

In the original session, System Integrity Protection blocked that in normal boot. SIP was not turned off. The directory was later removed from Recovery, with the volume name checked via ls /Volumes/ first. The follow-up that was actually observed was not a CPU number. Overnight, with the charger plugged in, the battery fell from 100% to 89%, and the menu said charging was paused because battery use was very small. That is written up in 删掉 CoreDuet 后，Mac 为什么突然不会省电了？. There was no backup of the directory, so there was nothing to restore. Deleting it again is not an undo.

Do not disable mds as a first look:

sudo launchctl disable system/com.apple.metadata.mds
sudo launchctl stop com.apple.metadata.mds

That stops the metadata server. Indexing and search stay off until you turn them back on. The notes used it so later file deletion would not race a writer. It is not a diagnostic.

If you still rebuild the index

Only after the read-only steps, and only if you accept a rebuild:

sudo mdutil -E /

Then wait. The original notes do not say how long the rebuild took, or what the CPU was when it finished. They do say the same command was used twice, once before looking at status and once after the CoreDuet directory was removed. Neither run is a recipe that was timed.

The matching enable commands written down at the time, and not rechecked for this page, were:

sudo launchctl enable system/com.apple.metadata.mds
sudo launchctl start com.apple.metadata.mds

If search is still dead after that, do not add another disable. Run mdutil -s / and read whether the switch is on or off.

When to stop

If the read-only checks still do not tell indexing from a repeated CoreDuet request, stop. Do not add a hand delete of /.Spotlight-V100, and do not treat a CoreDuet wipe as the next step. The day-of record, including what mdutil -E and the database delete actually changed, is the Chinese post linked above. The charging side effect is the CoreDuet post linked above.

• MacOS
• Spotlight
• Corespotlightd

If this post helps, you can sponsor the blog. This is voluntary personal support, not a charitable donation.