On Mon, May 08, 2000 at 10:56:43AM -0400, Bryan White wrote:
> > It's not even that hard, that was the first time I had ever fiddled
> with
> > the Kernel source. We went to 4096, which should allow for quite a few
> > qmail-remotes. : )
>
> Do you have any feel for how to evaluate what is an optimum number of
> remotes? At 400 remotes I still have 80% CPU idle time. The load average
> is around 4. This suggests to me that the system is limited by disk I/O,
> network I/O or the responsiveness of remote servers. If it is Disk I/O more
> remotes won't help. I track network traffic through our router fairly
> closely and don't think that is the bottle neck. If it is the
> responsiveness of remote servers then more remotes will help.
As always, there is a bottleneck. I like to see everything on an email
system as a set of queues. While some are tangible, such as the physical
mail queue, some are less so, such as the queue of I/O requests to the
disks, the queue of packets coming in and out of the interface, the
queue of processes to be run, the receiving servers at the other end, etc.
It is very rarely the case that all of these queues are in perfect
balance such that they all fill up and degrade at the same rate. Consequently
there has to be a slowest queue. That's your current bottleneck.
the slowest of those queues is going to be your current bottleneck. You
fix that, then the next slowest queue becomes your bottleneck. Keep fixing
until the first bottleneck comes around again, and you start the whole
process over.
As you say, in your case the bottleneck may well be disk or network I/O or
even a queue at the other end, namely the remote servers. If you have
good connectivity and a diverse range of recipients and a large
concurrencyremote, then it's probably not the remote servers.
But there's only one way to find out. Analyze each queue and find
out where it's currently at in terms of utilization. Start tuning
the queue with the highest utilization and you'll probably see
improvements.
Regards.
