On 7/06/10 11:24 AM, [email protected] wrote:
On Fri, Jun 04, 2010 at 02:07:55PM -0700, Darren Reed wrote:
Someone was complaining about a build server being slow, so I've just
started to look into it... and this thing called pkg.depotd seems to
be constantly near the top of top output... so what was it doing...
/2: 3.8359 0.0500 pollsys(0xFD75E380, 0, 0xFD75E3F8, 0x00000000) = 0
/1: 3.8829 0.1000 pollsys(0x08046F10, 0, 0x08046F88, 0x00000000) = 0
/2: 3.8860 0.0501 pollsys(0xFD75E380, 0, 0xFD75E3F8, 0x00000000) = 0
/2: 3.9361 0.0501 pollsys(0xFD75E380, 0, 0xFD75E3F8, 0x00000000) = 0
<snip>
Can you provide more data, please? What kind of build machine is this?
Is it SPARC or x86? Can you show how much CPU time is being used by
pkg.depotd, and of that time, how much is actually being used by
pollsys? The last time I investigated a problem where pkg(1) was making
too many syscalls, there was almost no time spent in the system call
itself, and far more of the time was spent in actual application-level
code. Also, on recent builds, pstack(1) can show you python stacks on
32-bit code. That may also be helpful for debugging, if the application
is indeed stuck in some kind of loop.
My apologies for this email, I mentioned a number of things
that weren't really related that probably implied incorrect
conclusions.
The point wasn't that pkg.depotd was causing system performance
problems but rather the idle loop wasn't particularly idle (when
compared to what I'm used to seeing.) As it turns out, the above
is normal for the breed of python being used.
So really, a squall in a teacup.
Darren
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
