:>Date: Mon, 6 Dec 1999 10:13:50 -0800 (PST)
:>From: Matthew Dillon <firstname.lastname@example.org>
:> The actual problem is sendmail's constant *rescanning* of the directory.
:To the extent that the directory is populated, yes. (Scanning an empty
:directory isn't an overwhelmingly resource-intensive operation.)
: (lots of good stuff removed)
:David Wolfskill email@example.com UNIX System Administrator
It's an O(N^2) failure mode. If your sendmail gets overloaded then queue
files build up which in turn make sendmail less efficient. The
result is a cascade failure - where the mail queue directory gets
so large that it cannot recover even when the load drops back down to
normal. We had dozens and dozens of such failures at BEST before I
went to the multi-queue method.
This obviously only applies to servers that have a lot of mail volume.
When you are getting four or five emails a second at peak and something
out of your control goes down, the queue can build up very rapidly.
I will also note that the problem is exasperated by FreeBSD's current
use of malloc buffers instead of the VM cache to cache directories. Once
any given directory gets too large, the machine suddenly starts going to
disk every time you scan it! In 4.x you can turn on VMIO backing for
directories (sysctl -w vfs.vmiodirenable=1). It isn't on by default
only due to a bug somewhere in softupdates that causes an occassional
panic, apart from that all the necessary work has been done (by yours
truely, of course :-)).
To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message