3

I'm trying to figure out if the spotlight process "mds_stores" is consuming more resources than it should be. I've turned spotlight on and off and reindexed everything but it's still regularly using between 40 and 80% of the CPU on my lightly loaded system and chewing through insane amounts of memory even after a reboot. Right now, the real memory and private memory it's consuming is over 32 GB on a 64 GB machine. This doesn't seem normal to me.

As far as I can tell, Spotlight finished indexing my drive over a day ago yet mds_stores is still consuming a bunch of resources.

I've told Spotlight to ignore my external drive and the caches. Is there anything else I can do?

12
  • Something is definitely wrong on your end. FWIW My system was rebooted 12 hours ago and at the moment I have one occurrence in Activity Monitor: mds_stores 0.0 22.19 4 0 0.0 0.00 295 root 153.9 MB 81.3 MB 44.1 MB 42.5 MB 0 bytes 0 bytes 0 bytes 0 bytes 0 0 (null) - No No No No Yes Yes 0 bytes 0 bytes (null) Commented Oct 24, 2021 at 19:53
  • OK, thanks for the feedback. I just discovered that when I tell spotlight to ignore the "Macintosh HD" volume, everything went back to normal. This isn't a proper fix, obviously, but at least it tells me the process itself isn't buggy. Theres's something somewhere on the drive that's making it go crazy.
    – StevieD
    Commented Oct 24, 2021 at 20:27
  • Interestingly, after adding "Macintosh HD" back to spotlight search (by removing it from the "Privacy" pane in Spotlight system preference), the amount of resources getting consumed are remaining normal.
    – StevieD
    Commented Oct 24, 2021 at 20:33
  • Hopefully it stays that way. Commented Oct 24, 2021 at 20:35
  • I just removed a bunch of folders from the Spotlight Privacy settings and memory is now hovering only around 1 GB but CPU usage has shot back up to between 50% and 200%. But that's because Spotlight is now reindexing those folders. I'll have to wait until indexing finishes and reboot to know for sure. I'll report back what I find. This seems to be a prettty common problem.
    – StevieD
    Commented Oct 24, 2021 at 20:43

2 Answers 2

0

After reindexing everything again and waiting a full 48 hours, CPU usage has finally dropped down to normal levels, using just around .1% of CPU for mds_stores and mds. Memory is still pretty high at around 18 GB of memory. While indexing, this number went up to as high as 44 GB on a 64 GB machine.

And it looks to me like mds_stores will continue to use a lot of resources even after the drives are indexed by Spotlight. Perhaps it is making the search index more efficient. At any rate, it took many, may hours to for this to happen before CPU usage dropped from roughly 50% to .1%. It could be a function of me having a 4 TB drive. I'm not sure.

But as far as I can tell, it seems to be working smoothly now.

1
  • Try rebooting and check the memory usage afterwards - the 18 GB figure could just be because of (unintended) memory leaks.
    – jksoegaard
    Commented Oct 26, 2021 at 20:57
-2

The system is designed to store data from the filesystem in memory so unless you need RAM for other things this is a benefit, intended and normal.

Below is a snapshot of a machine where I'm processing about 35 TB of data - rsync from several direct attached drives to other direct attached drives. About 900,000 files on each of the 5 connected drives, photos syncing, etc...

spotlight process memory usage on macOS Big Sur

I would look at your memory pressure graph in Activity Monitor and see what you see in terms of trends instead of one snapshot. Just because memory is allocated now, it can be de-allocated and freed in an instant if needed. Virtual memory is not like a physical warehouse where you have to move things out and it’s a problem to be 98% full. In fact, it’s the opposite, you are spending energy to keep RAM active always, so the system might as well use it all rather than waste it.

For context - here is the entire system memory contents sorted by the processes that allocate more RAM than others.

memory usage of all processes on macOS Big Sur

This Mac has been running for a month and mds_stores has used 9 minutes and 15 seconds of CPU time in that month.

CPU usage of mds_stores and spotlight on macOS Big Sur


In response to the comment that mds_stores does not grow and shrink, I run this command to check on it when I have a suspect "spotlight" issue:

% sudo vmmap -resident -w mds_stores|grep footprint
Physical footprint:         102.0M
Physical footprint (peak):  352.4M
15
  • This is not correct. When memory is shown as real and private memory allocated by mds_stores, it is not data that is cached from the file system, and it will definitely not be de-allocated and freed in an instant if needed.
    – jksoegaard
    Commented Oct 24, 2021 at 20:50
  • That's not been my experience @jksoegaard lately on Mojave and newer. As you can see - I push a lot of files on 8 GB RAM - if there were a problem with the OS - I would likely see it before someone that buys more RAM, don't you think?
    – bmike
    Commented Oct 24, 2021 at 20:54
  • Yeah, my understanding is that the real memory is what matters. I don't think 32 GB for something basically searching for files would be considered normal. Also, the CPU usage at 50% after everything had been indexed tells me something is wrong. And the memory getting freed up after removing the "Maciontosh HD" from Spotlight would also seem to indicate that spotlight is stuck on some file somwhere on the drive.
    – StevieD
    Commented Oct 24, 2021 at 21:07
  • 2
    I'd start with the CPU use for a day and the sudo vmmap -resident -w mds_stores|grep footprint to start. There's so, so, so much detail in the diagnosis scripts. It's taken me far too long to learn what is meaningful and what to ignore or pay Apple to fix when I get too deep in the weeds...
    – bmike
    Commented Oct 24, 2021 at 21:26
  • 1
    @bmike As written in the question, he's experiencing mds_stores using 32 GB of real and private memory. You answer that this is a benefit as the system is designed to store data from the filesystem in memory. But this argument is flawed - data cached from the file system does NOT show up as real and private memory allocated by the mds_stores process. That's not how that works.
    – jksoegaard
    Commented Oct 24, 2021 at 22:28

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .