Activitymonitord hogging CPU

YES! I have the same problem! The OS starts off snappy & fast, then after a few hours, windowserver hogs the CPU any time I activate expose, Safari hogs the CPU anytime I scroll, & activitymonitord randomly hogs the CPU when I have Activity Monitor open. Expose is so slow & choppy it's ridiculous. Any action I take on the computer takes 1-2 seconds before it activates.

Anyone? Any ideas? I upgraded from 10.5 to SL (not a clean install). I don't get it. It worked so well for some time. No new installs. Nothing.

Rishi

See:

Mac Maintenance Quick Assist,
Mac OS X speed FAQ,
Speeding up Macs,
Macintosh OS X Routine Maintenance
Essential Mac Maintenance: Get set up,
Essential Mac Maintenance: Rev up your routines,
Maintaining OS X, and
Myths of required versus not required maintenance for Mac OS X for information.

This is not some 'generic' speed problem. This is specifically after upgrading to Snow Leopard, and then enabling 64-bit. I'm wondering if it's a video driver problem with the 64-bit version, but I'm still confused why the OS starts off fast & then slows down to ridiculous speeds.

Rishi

I have no idea, since I don't run in 64-bit mode. What's the performance when running the 32-bit kernel? AFAIK, there's not much advantage to running in 64-bit mode, but that's for another day to discuss.

Basically, something happened that makes most programs use more CPU than they used to. Safari & Firefox can't even play youtube videos anymore without stuttering. MP3s can't even play without dropping out. Utterly ridiculous!

I switched back to the 32-bit kernel, but the problem persisted.

Tonight, I'm going to just re-clone my backup copy of the OS (from before I ever enabled 64-bit), and see if that helps.

Rishi

Well, in your case, I'd pursue doing the maintenance stuff. I've experienced no such slow downs the past year while running Snow Leopard, during beta-testing or since it shipped. I routinely run iTunes radio while sending e-mail and surfing the web and viewing youtube movies, never a stutter or miss.

Someone else with the same Macbook Pro model also had a similar problem where the CPU core temperature went up to somewhere near 100 degrees after he activated 64-bit kernel & extensions. Clearly something is very wrong here... I'll know more after I roll-back my OS to my previous installation (haven't had a chance to yet).

Hugh (OP), what's the status with you?

Also, don't know if this is relevant, but it's always just one core that maxes out... the other core hardly has any activity (as shown in Activity Monitor).

Strange.

An update:

I restored a backup copy of my OS (10.6.2), and all is fine (for 5 days now).

This is running 32-bit kernel & extensions.

Interestingly enough, when I took the installation that was slowing down, and reverted it back to 32-bit kernel & extensions, it didn't fix the problem. But going back to my old OS (which was never taken to 64-bit... i.e. the boot.efi was never modified) fixed the problem.

Doesn't really make any sense to me. It's like something about going to 64-bit then changed something else in the OS which then slowed it down & which couldn't be 'undone' by going back to 32-bit. But going back to the OS before I ever enabled 64-bit via a modified boot.efi fixed the problem.

Guess I'm happy enough for now, though this all remains strangely inexplicable.

Rishi

Rishi Sanyal wrote:
Doesn't really make any sense to me. It's like something about going to 64-bit then changed something else in the OS which then slowed it down & which couldn't be 'undone' by going back to 32-bit. But going back to the OS before I ever enabled 64-bit via a modified boot.efi fixed the problem.

Sounds like the problem was the modification of the boot.efi. You could check things out by staring up to the 64-bit mode--the usual way--holding down 6-4 when starting up.

Can't do that because Apple has entirely disabled even the possibility of 64-bit on the MacBook Pro 3,1. Maybe there are just some hardware issues & so perhaps they did that for a reason.

I even tried replacing the old boot.efi back & going back to 32-bit but even that did not help. I had to cleanly restore my old installation. That's why this is so confusing!

Rishi

Are any of you guys using Drobos? I have been experiencing the same problem with my Mac Mini. Unbelievable slow downs after the computer has been on for a while. When looking at activity monitor system processes are taking upwards of 50% of both cores of my processor (with activitymonitord being the highest). That's just ridiculous. No spotlight indexing going on, very few (if any) apps open, etc. One of the processes that occasionally was high was DDserviced, a Drobo Dashboard process. Apparently, version 1.6.1 of the Drobo Dashboard causes problems with non 64-bit compatible machines (like my several years old Mac Mini). Theoretically the next version on the Drobo Dashboard software will fix this, but it's not out yet.

I don't know if this is actually the cause for anyone else, but if so, here's a solution on macosxhints. I haven't tried it yet, but I'll try to remember to report back in a few days after trying it. http://www.macosxhints.com/article.php?story=20091106182154177

I haven't gone through all the steps in the link above, but I did try ejecting my drobo, then, from Activity Monitor forcing DDserviced to quit (the Drobo Dashboard process). It restarts itself, but once it fully quit (several seconds), my Activity Monitor CPU graph looked much more normal. No more processes hogging CPU cycles, including activitymonitord.

Just reporting back that after doing the clean re-installation of my 'virgin 32-bit system' (the one that had never been switched to 64-bit), my computer's been running fine for the last ~3 weeks.

Also, no way for me to retroactively go back & check if DDserviced was running when I was under 64-bit, but it isn't showing up as running now...

Rishi

I've got the same problems as you, it seems (Drobo hooked up to Mac mini, activitymonitord & DDserviced sucking up massive amounts of CPU after a period of time).

Going to try that tip from macosxhints to see if it helps.