Date: Wed, 15 May 2002 14:53:49 -0700 (PDT) From: Doug White <dwhite@resnet.uoregon.edu> To: Omar Thameen <omar@clifford.inch.com> Cc: freebsd-hackers@FreeBSD.ORG Subject: Re: tuning a CPU bound server Message-ID: <20020515144802.F869-100000@resnet.uoregon.edu> In-Reply-To: <20020515032425.A23491@clifford.inch.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On Wed, 15 May 2002, Omar Thameen wrote: > > First off, what are the specs of the server? Cpu? Disk? Memory? Network? > > You mention it's a dual 800MHz. What kind of NIC does it have? What is the > > speed and duplex set to on it? > > Dual PIII/800 > 2G SDRAM > 2x18G IBM 10,000 rpm SCSI drives, running vinum RAID0 because I > originally thought disk accesses would be a bottleneck (but they aren't) > Tyan Thunder LE S2510 motherboard: > sym0,sym1 SCSI controller (on board, one drive on each channel) > fxp0 network (on-board), 100M, full-duplex The scsi version of the cursed board. We have lots of these laying around. > Will do. Since there's no big delivery happening at this moment, I'll > follow up later. Last I checked, it wasn't running out of mbufs > (kern.ipc.nmbufs: 34816). Can you post a netstat -m from now? It will have the peak values in it. > > qmail is also very inefficient when it comes to large delivery -- the fork > > per message and the qmail-remote trigger-hitting will eventually > > bottleneck you. It's probable you've run into it. My sympathies. :) You > > might try *dropping* concurrencyremote somewhat to reduce the > > context-switch thrash (although your context-switch numbers aren't too > > high, I've seen worse and the machine wasn't taxed too heavily). > > I've grown to this concurrencyremote fairly gradually. There was > improvement up to about 600 concurrencyremote. I added a 2nd > identical qmail queue so the deliveries wouldn't be so serial, but > didn't see anywhere near a doubling of the delivery capacity. When > only one of the queues is delivering, I see very similar vmstat > and throughput values. You've hit the limits of what the system can fork off. The solution then is to reduce the amount of forking going on. Make sure any alias files or whatever gets commonly hit on your machine avoid calling shells at all costs. Shells take a long time to start up and are slow which will slow down your throughput. It's easy to accidentally trigger shell starts if you use metacharacters in your alias files. If your mail processor can be called directly, try to arrange it so it is instead of going through an intermediary shell. > It's dnscache (~30%), then the 2 qmail-rspawn processes (~20-25% each). > I thought about running dnscache on a separate server, but don't > think that will give the performance improvement I was hoping for. I don't know much about dnscache and its characteristics, but that might be somewhere to concentrate on to get a few % cpu back. The rspawns sound about right from my experience. Moving it to a separate box, if useful, might be a good idea, at least to try. Running two qmail instances on the same machine is probably hurting each other, so you might want to collapse them back into one. Doug White | FreeBSD: The Power to Serve dwhite@resnet.uoregon.edu | www.FreeBSD.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020515144802.F869-100000>