Date: Tue, 13 Jan 2004 11:13:28 -0800 From: Peter Losher <Peter_Losher@isc.org> To: current@freebsd.org Subject: FreeBSD 5.x performance tips (ISC) Message-ID: <200401131113.29012.Peter_Losher@isc.org>
next in thread | raw e-mail | index | archive | help
=2D----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Thanks for the responses so far, many privately, I'd like to respond to the= m=20 via one message, rather than a bunch of tiny ones. To give you a better picture, ths system handles ftpd (less than 500 client= s)=20 & 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) = =20 PCI RAID controller, as well as a external HP Virtual Array hooked to the=20 host via FC (Qlogic) - The array is the one doing the heavy disk I/O (it ha= s=20 all of the mirrored content) Right now iostat is stating that the array is= =20 pushing out 4.40MB/sec - It's usually in the low-mid 4MB/sec range at high= =20 traffic levels. And just to round out things, the NIC is a Intel Fiber Gi= gE=20 PCI card.=20 > 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=20 always reported as *Giant, the top 4-5 ftpd process are also *Giant; the re= st=20 are either biord, sbwait, or in one or two cases accept. httpd processes a= re=20 almost all selects. The load average w/ a SMP kernel is 1-3, in a non-SMP kernel, it's around 5= 0. > 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= =20 showed some lockup issues at boot with it. (and I assume you are still usi= ng=20 the 4BSD scheduler?) > Hmmm..... Peter, I don't know if anyone has advocated this or not, but h= ave=20 > you tried the ULE scheduler? I have been using it on SMP and UNI machine= s=20 > 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=20 vmpanics so it may not have ever gotten a fair shake... Hopefully this illuminates more light on the issue, I will probably try add= ing=20 ZERO_COPY_SOCKETS & ADAPTIVE_MUTEXES later today when the load dies down. Best Wishes - Peter =2D --=20 Peter_Losher@isc.org | ISC | OpenPGP 0xE8048D08 | "The bits must flow" =2D----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (FreeBSD) iD8DBQFABENYPtVx9OgEjQgRAgv1AKCT9FM53zMbumLMqO5n4jooUggN4ACgk1xl rli3iPvfaiDBbRmJpCdITiU=3D =3D1BFS =2D----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200401131113.29012.Peter_Losher>