Jeremy Hansen <[EMAIL PROTECTED]> wrote:
>
> Is there any kernel sysctl or otherwise parameters suggested for
> performance using qmail on Linux? Open file handle limits, share
> memory, whatever? I have a goal to send at least 1 million emails in
> a 24 hour period from a single machine.
The main suggestion has already been made: raise concurrencyremote to
255 and buy lots of memory.
If money is not an object, you can also install several SCSI drives
and stripe /var/qmail/queue across those disks. (Mount the filesystems
with the "sync" option, for reliability.) Disk I/O is a potential queue
bottleneck, especially on one-disk Linux boxen. Also, you might want to
look for faster filesystems than ext2--but what, I'm not sure.
If money _is_ an object, then save memory every way you can. That
includes,
* Never running X on the qmail server.
* Deactivating inetd. Turn on _critical_ services using tcpserver and
supervise, with _very_ low connection limits (e.g., 2 simultaneous
telnet connections).
* Turn off all unused daemons. This probably includes lpd, nfsd, mountd,
the portmapper and RPC daemons, Apache, ftpd, and most services run
from /etc/inetd.conf. (For security's sake, you might turn on sshd and
throw away telnetd entirely. Throw away sshd if remote admin is not an
issue--not!)
* Throw away or reconfigure ``locate''. The locate database is rebuilt
daily, causing a several-minute spike in disk usage.
I'd be surprised if _kernel_ tuning were an issue. The reason qmail smokes
is that it is extremely thrifty of system resources.
You might tinker with priorities, though. Re-nice-ing one or more of the
qmail daemons may keep qmail running strong during times of system load.
After all, that's what priority means!
Good luck!
Len.
--
Huh? There are lots of packages with compiled-in pathnames. Ever tried
moving X?
-- Dan Bernstein
