Date: Mon, 6 Dec 1999 10:13:50 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Peter Jeremy <jeremyp@gsmx07.alcatel.com.au> Cc: hackers@FreeBSD.ORG, rfg@monkeys.com Subject: Re: tmpfs .. ? Message-ID: <199912061813.KAA70974@apollo.backplane.com> References: <99Dec6.092620est.40335@border.alcanet.com.au>
next in thread | previous in thread | raw e-mail | index | archive | help
:On Sat, 04 Dec 1999 15:44:49 -0800, "Ronald F. Guilmette" <rfg@monkeys.com> wrote:
:>Specifically, I'm planning a large mail server... which will use Sendmail...
:>and I'd really like to allocate the Sendmail queue files... which typically
:>have a rather short lifespan... on/in some sort of filesystem (e.g. an
:>mfs or else this VN thing you are talking about) that would tend to give
:>petter performance than just using an ordinary disk-based filesystem.
:
:This doesn't sound like a good application for a temporary filesystem.
:Whilst the files do typically have a short lifetime, and there are lots
:of them, they represent mail items which your server has accepted
:responsibility for delivering. Also, the queue files can potentially
:exist for several days (the default timeout is 5 days).
:
:I would suggest that UFS with softupdates represents a better performance/
:reliability tradeoff than MFS or a swap-backed vnode.
:
:The main problem is that sendmail places all queue files (and there
:are several for each undelivered message) in one directory - and very
:large directories are not handled particularly efficently by UFS. The
:simple solutions are:
:1) switch to an alternative MTA that doesn't display this behaviour.
:2) hack sendmail to have multiple subdirectories within the main
: queue directory - with the subdirectory chosen by hashing the
: sendmail job id.
:
:Peter
The actual problem is sendmail's constant *rescanning* of the directory.
So you don't really need to hack sendmail to fix it though it would be
nice if sendmail built the feature in. What you want to do is move the
queue file to a queue directory based on the number of retries that have
occured on the queue file. You then run fewer sendmail -q's on the
directories representing higher retry counts and more sendmail's on the
directories representing lower retry counts.
The retry count happens to be a field in the queue control file so it's
relatively easy to write a program to move queue files around baed on it.
You have to be sure you properly lock the queue file while renaming it,
of course, so you cannot (easily) use a script, and you have to test for
duplicate queue id's so you do not rename-over, but that's it.
Running sendmail's on multiple queues is trivial:
sendmail -q1m -OMaxDaemonChildren=50
sendmail -q1m -OMaxDaemonChildren=20 -OQueueDirectory=<queuedir1>
sendmail -q1m -OMaxDaemonChildren=10 -OQueueDirectory=<queuedir2>
sendmail -q1m -OMaxDaemonChildren=5 -OQueueDirectory=<queuedir3>
sendmail -q1m -OMaxDaemonChildren=5 -OQueueDirectory=<queuedir4>
sendmail -q1m -OMaxDaemonChildren=5 -OQueueDirectory=<queuedir5>
sendmail -q1m -OMaxDaemonChildren=5 -OQueueDirectory=<queuedir6>
...
I used this trick at BEST and it works extremely well.
-Matt
Matthew Dillon
<dillon@backplane.com>
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199912061813.KAA70974>