Skip site navigation (1)Skip section navigation (2)
Date:      Thu, 15 Dec 2011 15:35:39 -0600
From:      Dan Nelson <dnelson@allantgroup.com>
To:        Jeremy Chadwick <freebsd@jdc.parodius.com>
Cc:        Doug Barton <dougb@freebsd.org>, freebsd-stable@freebsd.org
Subject:   Re: swi4: clock taking 40% cpu?!?
Message-ID:  <20111215213539.GJ53453@dan.emsphone.com>
In-Reply-To: <20111215210421.GA33083@icarus.home.lan>
References:  <4EEA5DD0.1040009@FreeBSD.org> <20111215210421.GA33083@icarus.home.lan>

next in thread | previous in thread | raw e-mail | index | archive | help
In the last episode (Dec 15), Jeremy Chadwick said:
> On Thu, Dec 15, 2011 at 12:51:28PM -0800, Doug Barton wrote:
> > Web server under heavy'ish load (7 on a 2 cpu system) running
> > 8.2-RELEASE-p4 i386 I'm seeing this:
> > 
> > PID USERNAME PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
> > 12  root     -32    -     0K   112K WAIT    0 129:01 39.99% {swi4: clock}
> > 
> > Any ideas why the clock should be taking so much cpu? HZ=100 if that
> > makes a difference ...
> 
> Could be wrong, but I believe this correlates with IRQ 4.  What does
> vmstat -i show for a total and rate for irq4 if you run it, wait a few
> seconds, then run it again?  Does the number greatly/rapidly increase?

That would be "irq4" in that case, though.  "swi4" is just a software
interrupt thread, and "clock" is the softclock callout handler.  There are
both KTR and DTrace logging functions in kern_timeout.c, so you could use
either one to get a handle on what's eating your CPU.  Busy-looping
"procstat -k 12" for a few seconds might get you some useful stacks, as
well.
 
> Shot in the dark here, but the only thing I can think of that might
> cause this is software being extremely aggressive with calls to things
> like gettimeofday(2) or clock_gettime(2).  Really not sure.  ntpd maybe
> (unlikely but possible)?  Sort of grasping at straws here.

-- 
	Dan Nelson
	dnelson@allantgroup.com



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20111215213539.GJ53453>