On 2017-04-11 10:02:21 (-0400), Wietse Venema <wie...@porcupine.org> wrote:
Fazzina, Angelo:
I would think they would have to tell you the volume and or rate at
which they intend to send the mail.
He mentioned message count and size, about 100GB of traffic, so that
might take a while, especially when the queue is on spinning disks.
It is worth repeating that the spinning rust actually matters in this
case: Postfix fsync()s when accepting a message into the queue. The
time to it takes to enqueue a message is at least the time it takes to
write it to disk, not simply the time it takes to hit the buffer cache.
People occasionally forget that Postfix actually tries to be reliable in
addition to fast. :)
Mounting /var/spool on an SSD is definitely a good idea. Ideally a
mirrored pair of SSDs for reliability.
If you're running on ZFS, you want your ZIL on fast SSDs (again: plural,
and remember to mirror them, by default ZFS load-balances log devices).
(If you don't care about reliability, mount /var/spool on a tmpfs. Or
build Postfix without HAS_FSYNC. If it breaks you get to keep the
pieces though.)
- If the sender's DNS setup is borked, Postfix will lose time doing
DNS lookup for the SMTP client name/address.
Running a local resolver (e.g. Unbound) can mitigate most of these
issues. Also be sure to check that the TTL of the SMTP client's DNS
name / zone are configured sensibly. If it's got a TTL of 5 seconds,
you can do all the caching you like and you'll still be doing a lot of
waiting for DNS. (This can be mitigated with the cache-min-ttl setting
in Unbound).
Philip
--
Philip Paeps
Senior Reality Engineer
Ministry of Information
