On Wed, May 10, 2000 at 01:30:53AM -0700, Flemming Funch wrote:
> At 09:39 AM 5/9/2000, Matthew B. Henniges wrote:
> >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)
> >concurrency remote at 500
> >concurrency local at 50
> >FreeBSD 3.4-S
> >localhost dnscache
> >
> >It will push 12 Million on a good day. (4% local delivery).
> >
> >This is qmail 1.03 + big-todo + big-concurrency + qmailqueue
>
> I'm green with envy. Now, I administer around 6 qmail servers. Typically a
It's not clear to me that these are valid comparisons. Is the 12mill per day
mean 12M individual messages individually queued? Are is it a much smaller
number of messages with a larger number of recipients?
> dual-600PIII with 1G of RAM, with /var on a 10K SCSI, and everything else
> on other disks. I also use qmail 1.03 + big-todo + big-concurrency. Remote
> concurrency set for 200. Queue set for a split of 293. Linux RH6.1 or 2.
> Outgoing mail is handled on different servers than the incoming. The
> machines are co-located on several different networks with plenty of bandwidth.
>
> The machines are mostly sending out daily newsletters which are being fed
> in from another machine by smtp or qmtp (seems to make no difference in
> performance which I use), and I've experimented with various numbers of
> incoming smtp processes.
>
> If I'm sending more in more than a couple of smtp connections at the same
> time (e.g. 10 or 20), concurrent remote processes drop to a crawl of 2-10,
> the machine's load gets really high, 6-20, and the queue gets filled up
> quickly.
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?
>
> What is localhost dnscache about? A local name server, to limit outgoing
> DNS lookups?
The speed lookups. It may be useful to you, but it's not relevant to your
low qmail-remote rate. It would actually exacerbate it in a sense as qmail-remotes
would probably taken even less time to do their work.
It would be especially interesting to see:
qmail-qstat, vmstat and maybe iostat (or their moral equivalent) when you
have no mail being submitted via qmqp/smtp, have a large queue of ready
messages and you are not achieving your concurrencyremote.
Regards.
