Re: AFP eating up CPU

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?