On 23/10/2008, at 9:21 AM, Dan Shoop wrote:
> You presume that there's a single cause to this. Unfortunately it's
> not that simple. Your problem is likely different from others.
>
> Given dtrace and sc_usage you can look deeper.
>
> Remember though that %CPU is not a metric, and if a process is
> consuming most all the CPU that this implies there's no other
> processes that are competing for CPU significantly.
>
> What normally you find is that when processes are using "excessive"
> cpu that they're spending a large amount of system time, which
> indicates something fundamental wrong, like latency issues, bad DNS,
> misconfiguration etc. It's spending time there b/c it's made system
> calls that aren't getting serviced. Find out why and you solve your
> mystery. Other issues occur when you've got waits that never return.
> That indicates, again, something fundamental that's out of line or
> problematic.
..to follow up on this, I have a machine (dual quad-core intel xserve,
10.5.4) that's been sitting at 50% CPU load for the last few weeks no
matter how many (or few) actual connections there are. (this machine
replaced a dual G5 who's AFP was consistently using 150% cpu so i
guess it's an improvement)
so on Dan's hint i ran sc_usage against the AFP process and, although
it's mostly all greek to me, it did seem that there were a lot of
calls to swtch_pri going on. (I should've kept a grab of the figures,
but the number against swtch_pri were massive compared to the other
calls.)
where it got interesting was when i decided to restart AFP from
serveradmin. in a nutshell, it wouldn't. I couldn't kill -9 it
either.. it was a zombie. But looking at sc_usage again there was
swtch_pri all by itself still raking up the numbers... and with a
pretty guilty look on it's face if i do say so.
So i rebooted the box and now the cpu graph is at a normal level, and
there's no mention of swtch_pri cropping up at all in sc_usage.
Bit of googling led me to
http://www.gnu.org/software/hurd/gnumach-doc/Hand_002dOff-Scheduling.html
which describes swtch_pri thusly:
> The system trap swtch_pri attempts to switch the current thread off
> the processor as swtch does, but depressing the priority of the
> thread to the minimum possible value during the time.
Sounds great. Now, would anyone have any idea how i can use this
information to fix my server.. or is it bug report time?
..S.
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Macos-x-server mailing list (
Macos-x-server@...)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/macos-x-server/lists%40nabble.comThis email sent to
lists@...