Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 16 Mar 2004 18:06:01 +1100
From:      Peter Jeremy <PeterJeremy@optushome.com.au>
To:        freebsd-hackers@freebsd.org
Subject:   Re: kernel activity
Message-ID:  <20040316070601.GK56509@cirb503493.alcatel.com.au>
In-Reply-To: <20040315150438.GA48241@icomag.de>
References:  <20040315150438.GA48241@icomag.de>

next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, Mar 15, 2004 at 04:04:38PM +0100, Bogdan TARU wrote:
> I'm running a pretty busy webserver, and right now I can see it's
> CPU-bound:

A few more details would be useful:
What version of FreeBSD?
What hardware are you using (CPU and NIC in particular)?
What application(s) are you running?  You mention a webserver - which one?
  Is it just serving static pages or is there lots of dynamic content
  (CGI or servlet etc)?  Any other applications?
Do you have firewall software running?  If so, which?  Is it simple (a dozen
  or so rules) or complex (thousands of rules)?
What FreeBSD tuning have you done?
How does your kernel config compare to GENERIC?
What (if any) malloc(3) are you using?
If the CPU supports HTT, have you tried turning HTT on and off?

>84 2 0 1135836 142692   82   0   0   0 405   0  35   0 3144 246325 1739 42 58  0

You have very high interrupt and system call rate - both of these
contribute to system time.

I presume most of the interrupts are from your NIC.  Have you considered
using polling mode (see polling(4))?  Some NICs are more efficient than
others - fxp(4) is one of the best, rl(4) is probably the worst.

It's difficult to say whether the syscall rate is excessive or not.
The number of system calls is generally up to the application - you
need to tune or redesign it to reduce the number of system calls it
makes per unit of work.  That said, I've noticed that threading on
-STABLE adds quite a significant overhead - via high system call rate
and system time.  In one case, I improved the throughput of a graphics
manipulation process by about 10% by removing the threading.

It's difficult to get much visibility on where system time is going
(though "systat -v" will split out interrupt time).  In theory, you
could build a profiling kernel but this is non-trivial and may or may
not be functional at present.

Peter



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