Is MDS taking over your CPU on OS X? Try Spotless.
June 24th, 2007My 5 month old MacBook Pro often has the MDS process chewing about 45-50% of CPU at various points in the day. Given that MDS is supposed to sit around and casually index – so that Spotlight can quickly perform a search, this CPU usage pattern is a red flag. Chances are something is wrong with either the disk or the Spotlight metadata index [what MDS manages]. After using Disk Utility to verify the volume, I tried Spotless. It worked great.
Spotless is a nice little $15 nagware utility made by Fixamac Software that helps you delete and recreate the Spotlight metadata folder and index, so that it can let MDS rebuild from scratch. It offers a few other moderately useful features, but if MDS is getting aggressive, this makes it real easy to get a clean rebuild.
Update 8/11/09: JS points out comments that you can instruct MDS to clear out the metadata cache and rebuild from scratch using this command run from Terminal:
sudo mdutil -avE
This is effectively what Spotless does, but without the user interface.
June 24th, 2009 at 4:25 pm
you really shouldn’t pay for something like this. just learn to use mdutil—it’s only one command to turn indexing on off and another to force re-indexing.
June 24th, 2009 at 6:03 pm
ST – how about you save everyone some money and tell us what command to enter! :)
June 25th, 2009 at 9:56 am
Um.. looks like he did.. the command is mdutil.
go to /Applications/Utilities/Terminal, start a shell, and type mdutil
June 25th, 2009 at 10:25 am
To clarify – I know about mdutil, but some other people arriving at this post might not feel awesome about rooting through a man page or USAGE printout.
July 7th, 2009 at 5:35 am
Open a terminal: mdutil -i off
By just typing mdutil you get some usage information.
Also, the man-pages are not evil, to survive in a *nix environment you need to learn to read them.
July 20th, 2009 at 2:55 pm
sudo mdutil -a -v -i off to see that it turned off indexing on connected volumes
July 31st, 2009 at 1:34 am
[...] and Textmate is a no brainer, but I didn’t know what or how to address the problem with mds. Come to find out, mds is responsible for indexing in Spotlight. If its thrashing your CPU and hogging up your RAM, [...]
August 9th, 2009 at 6:51 pm
Erm… for those who are tired of hearing people say “read the man pages” for a Mac, the one simple command to clear out potentially corrupted metadata and rebuild the store from scratch (which is the feature of Spotless being discussed here) is:
That is, sudo (because you have to have admin rights to run this), mdutil (the program that does the work for you) -a for “work on all volumes”, -v for “be verbose in telling me what you’re doing”, and -E for “erase the data store and rebuild it”.
Honestly guys, why do we have to make every question an opportunity to be superior and arrogant? Yes, mdutil is the command. Did it not occur to you that the question was asking for the specific usage to accomplish this task? So why answer like you didn’t get that? Because you want to show that superior users can read the man pages? Because you feel it’s your responsibility to help people realize that they can’t survive on a Mac without being able to read man pages?
Come on. This isn’t Slackware. This isn’t Gentoo. This isn’t Solaris. This nix platform is marketed specifically to people who don’t *want to have to RTFM to get by. Give them a break and just answer the questions.
August 11th, 2009 at 8:19 am
Thanks SO much, JS.
I’m probably a bit more tech savvy than your average Mac user, but without clear guidance like yours, I’d be lost.
August 25th, 2009 at 2:33 pm
@JS: AMEN! There are a lot of little utilities that Apple includes in Mac OS X that aren’t standard *NIX utilities. This just happens to be one of them.
By the way, this cleared up my 193% CPU usage of MDS under 10.6.
September 5th, 2009 at 9:00 am
the same here…just installed 10.6 and mds was going 150% cpu usage….now with the sudo mdutil -avE trick works perfectly…thx to all..
October 18th, 2009 at 1:46 am
Any idea on why we have to use this unix script to solve a problem that shouldn’t exist? I’ve seen kernel_task equally being driven crazy. This code fixes mds, but what’s really driving this instability in 10.6.1?
October 18th, 2009 at 2:42 pm
sudo mdutil -avE appears to have solved the problems. That and a disk repair. Apple should have some OS correction that limits this part of the indexing program.
Can anyone recommend a good book on these support codes?
November 6th, 2009 at 12:52 pm
I had mds at 95% of CPU with 10.6.1. Just did the sudo mdutil -avE command, but a minute later mds was back along with mdworker at 95% combined. What’s up? Did I do something wrong?
November 10th, 2009 at 6:56 pm
Is there any way of telling which drive is being indexed by mdutil at any given time?
November 10th, 2009 at 6:59 pm
Woooo Whooo… didn’t want to sound like I couldn’t read… so looked at the man page for mdutil and found I could do this:
mdutil -s -a
This told me the status of indexing for all of my volumes. Status… simply whether indexing was enabled or disabled. So… I still don’t have my answer.
November 10th, 2009 at 7:48 pm
Did you try :
sudo mdutil -sav
The v (verbose) may give you a bit more info.
HTH
November 15th, 2009 at 5:42 am
I got tired of the high cpu usage and just turned indexing off. Just as I did on my Windows machines. Google Desktop is actually a worthy substitue and I haven’t had any CPU usage problems with it yet.
December 8th, 2009 at 9:23 am
This is a great tip. I suddenly started having lots of hard disk usage after setting up a Boot Camp partition (related?), and I’m suspicious now that it’s mds, so I’m rebuilding my indexes.
I never used to hear anything out of my hard drive on my MBP before the Boot Camp partition was created — now I hear it rattling away all the time! Anyone else experience this?
December 8th, 2009 at 4:59 pm
OK for the CPU question. Is there a way to put it on a memory diet? It’s currently taking 500MB real (650MB virtual) memory that could go to better use in Firefox or NeoOffice, the two pigs that I want to feed.
December 30th, 2009 at 9:26 pm
JS Thank you very much! I suffered the agony of a slow mac for two weeks, countless hours trying to figure this thing out. Thanks again.
January 4th, 2010 at 8:47 pm
The cause of this process peaking out the cpu at a constant 100% seams to be related to having Boot Camp volumes. Simply dragging the Boot Camp volume to the trash to unmount t makes the process immediately drop down to 0% utilization. Not sure if there is a more permanent way to fix this, there is a way to add exclusions but that involves writing a file to the volume witch is read only. (Or maybe its related to the fact that it used to use the NTFS3G driver for read/write and I changed it back to the OSX native read only driver.)
January 5th, 2010 at 7:18 am
Well, being a Mac lover myself, and finding it easy to use the terminal (Due to an abundance of experience with Linux) I have no problems with these occasional bumps along the way. However, for the majority of the ignorant folks on the PC side of things, this sort of stuff is “unacceptable”. How many terminal commands do you have to enter to repair functionality in windows, along with the disk permissions and the disk repair issues? Hell, most windows users do not even know they need to defrag. However, the windows folks would rather deal with a slow, virus laden, severely fragmented computer, because if everything works they don’t care for the most part, even if it has slowed to a crawl. Whereas OS X is rock solid 99% of the time, but when there is a problem, the solution is often a severe pain in the shitter… Though I would happily be inconvenienced for an hour than to be bogged down by needing an antivirus software to scan every single file I open….
~Jacob
January 5th, 2010 at 6:01 pm
Better then the age old “Your gana have to reinstall windows!”.