FreeBSD 5.x performance tips (ISC)

Peter Losher Peter_Losher at
Tue Jan 13 11:13:34 PST 2004

Hash: SHA1

Thanks for the responses so far, many privately, I'd like to respond to them 
via one message, rather than a bunch of tiny ones.

To give you a better picture, ths system handles ftpd (less than 500 clients) 
& cvsupd (15 max clients), and to a lesser extent httpd.

> I'm not familiar with the hardware that you folks have, so maybe
> this is redundant, but, coming from a systems perspective, I can
> guess that you need faster I/O channels and more disk/etc bandwidth.

It has internal SATA drives hooked up to a 3ware SATA (64-bit / 66MHz bus)  
PCI RAID controller, as well as a external HP Virtual Array hooked to the 
host via FC (Qlogic) - The array is the one doing the heavy disk I/O (it has 
all of the mirrored content)  Right now iostat is stating that the array is 
pushing out 4.40MB/sec  - It's usually in the low-mid 4MB/sec range at high 
traffic levels.   And just to round out things, the NIC is a Intel Fiber GigE 
PCI card. 

> What state does top report these processes in? On a busy ftp server, I
> would expect *Giant, getblk, biord or select. What kind of load averages
> are you seeing under load, and when somewhat idle? If this system is
> currently contending on Giant, 5.2 will still exhibit this behavior but to
> a lesser degree.

Apologies for not mentioning the cvsup server, but most of those processes are 
always reported as *Giant, the top 4-5 ftpd process are also *Giant; the rest 
are either biord, sbwait, or in one or two cases accept.  httpd processes are 
almost all selects.

The load average w/ a SMP kernel is 1-3, in a non-SMP kernel, it's around 50.

> For a little performance boost, try the ZERO_COPY_SOCKETS and
> ADAPTIVE_MUTEXES combo in your kernel config. It Works Here (TM). :)

Are you using ADAPTIVE_MUTEXES in a SMP-aware kernel?  Googling on the term 
showed some lockup issues at boot with it.  (and I assume you are still using 
the 4BSD scheduler?)

> Hmmm.....  Peter, I don't know if anyone has advocated this or not, but have 
> you tried the ULE scheduler?  I have been using it on SMP and UNI machines 
> and it seems to do a better job of keeping loads much more in control.

I remember trying SCHED_ULE at some point but I think that was during the 
vmpanics so it may not have ever gotten a fair shake...

Hopefully this illuminates more light on the issue, I will probably try adding 
ZERO_COPY_SOCKETS & ADAPTIVE_MUTEXES later today when the load dies down.

Best Wishes - Peter
- -- 
Peter_Losher at | ISC | OpenPGP 0xE8048D08 | "The bits must flow"
Version: GnuPG v1.2.4 (FreeBSD)


More information about the freebsd-current mailing list