To throw my $.02 at this issue, if this is looking like a "low level" speed
issue, why not tinker with the hardware? Taking the two disks that hold
/var and putting them on a RAID0 set should give you a serious speed boost
without touching your (otherwise working) qmail config.
-----Original Message-----
> >On a dual celeron 466 with 512Mb ram. and 3 10k scsi drives (one for
> >/var/qmail/queue, one for /var/log, one for /usr/home)
While it's hard to tell without looking, by guess is that your inbound
submission rate is killing the spindle that your disk lives on.
> If nothing is coming in, the remote processes usually are 20-80, and only
> on a very rare occasion would get close to my 200 concurrencyremote.
That suggests to me that something is awry. I have never seen any properly
setup system achieve the configured concurrencyremote. Not getting your
concurrencyremote implies that qmail-send (via qmail-rspawn) cannot fork
prepare a message and fork a qmail-remote process quickly enough to keep
up with the exit rate. Thus *usually* means that qmail-send hasn't
sufficient
resources (such as spindle or file system performance).
> So .. eh... would it likely be my disk I/O that slows it down (how do I
> test that?), or should I be switching to FreeBSD, or am I doing something
> stupid?
