[Mailman-Developers] Re: To VERP or not to VERP?
J C Lawrence
Sun, 17 Jun 2001 09:39:47 -0700
On Sun, 17 Jun 2001 08:41:56 -0700
Chuq Von Rospach <email@example.com> wrote:
> the amount of disk it takes isn't an issue (within reason) --
> remember, it's going to start sending right away, so message will
> be gone out of the queue.
This is not a safe assumption. Exim for instance will defer
deliveries if more than N messages are received in a single
connection. As a result, you typically get no outbound deliveries
going on during a qrunner broadcast.
> You don't queue it all up and then start delivery.
> But this generates disk IO, and that can start bogging you down if
> you don't tune things properly. That means taking advantage of
> sub-folders in your mail queue for any MTA that allows them (the
> #1 performance death for a typical sendmail system: write-locks on
> /var/spool/mqueue, since every sendmail process has to create
> files in that directory. If you haven't set up subfolders, you are
> (I say this in a nice way) an idiot. if you aren't using a version
> of sendmail that allows for them, I'll call you an idiot in a
> not-nice way. Anyone not running at least 8.10 is hosed, so forget
Great READ/FAQ topic.
> Most MTAs are sensitive to this and work to minimize the
> impact. Even sendmail finally figured it out. But you still need,
> in large e-mail environments, to look at splitting this across
> heads and spindles. My experiments have indicated you're better
> off having mail on separate spindles than you are building a RAID
> using those same spindles, for whatever that's worth.
I've done similar experiments with news spools. The values are
incredibly subjective to RAID stripe size. Bob Mende IIRC did some
interesting work here which I think he presented at LISA.
FWIW We ended up with a 1Meg strip size as the sweet spot, much
bigger than we'd expected.
> And if you have lots of RAM, you can start using ram disks, and
> then you have lots of fun... (yes, I've done that. It's amazing
> how much faster sendmail is when you remove the disk I/O on those
> directory inodes...)
Silicon disks are another one. At Critical Path we used solid state
disks for /var/spool and Qmail fairly, umm, whirred.
J C Lawrence firstname.lastname@example.org
The pressure to survive and rhetoric may make strange bedfellows