On Sun, 31 Jan 1999, David Villeger wrote:
> - event though the concurrencyremote is set to 120, the number of
> qmail-remote never gets higher than 40. If some other program runs at the
> same time (like a bouncer handler, or a mail generator), the number of
> qmail-remote drops to 5! What should I increase to bump it up? (memory,
> cpu,...)?
Your processes have probably inherited the ulimit of whoever started them.
Run "ulimit -u some_big_number" before running qmail-start (perhaps this
is a FAQ?)
> - The todo and intd directories get very big under high load. On one
> machine, I've seen it reach 1.5 megs (just the directory file, not the
> content of the directory). How does this impact performance?
Sort of depends upon the filesystem (and disk). With a decent disk and
enough RAM, you're not likely to see too many problems here from Solaris.
I'll be interested to see some qmail benchmarks on reiserfs + Linux 2.2.
> - Because of the ease in administration, all the machines have the same
> configuration. That means that one machine does different things (create
> the unique emails and then call qmail to send them). Would it really make
> sense to split these functions on separate machines and have them
> communicate with qmqpc/qmqpd? It seems to me that with the same number of
> machines, I will get the same performance overall (not just qmail).
> Besides, the email creation is a sporadic process and I don't want to see
> any machine idle while the others are working. Am I completely wrong?
Depends upon how intensive your email generation is, I guess. qmail
places a very low load on CPU.
> - What is the cost of forking a qmail-inject for each email sent? What
Under Sparc Solaris? Quite high, but not unacceptable. Under Intel
Solaris? Very high, but not quite unacceptable.
> would I gain by opening a qmqp connection to another machine and
> continuously feed it with emails to send? Is this possible, or easy?
> - What would I gain (in terms of performance) by getting rid of fsync in
> qmail-send? What would I lose in practice (not in theory)? These machines
> practically never crash.
Win: a little less disk activity.
Lose: A few mails turn out truncated, as junk or not at all. Not to dis'
your service, but I get a few "personalised" emails, and if a few went
missing, I'm sure I could cope.
> - Is there any code modification that would significantly speed up qmail,
> even at the cost of less reliability (to a reasonable extent)?
Most qmail patches add functionality, rather than increasing efficiency.
I'm not aware of any which significantly increase throughput..
Matthew.
