5

Given the very specific nature of the subject (we're not talking about mailboxes, just the spool; we're not talking about other filesystems, just ext3; and so on...) and the maturity of the softwares involved (linux kernel, ext3fs, postfix) I'd think there should be a more or less agreed on set of best practices to filesystem related tuning.

I'm trying to get a roundup of them:

  • data=journal became the default in recent kernels (somewhere around 2.6.30 IIRC) so we should be ok with that
  • Wietse Venema says atime must be on, but Postfix documentation recommendsnoatime while talking about the Incoming Queue. Does that mean that postfix needs atime on just for some queue directories and will benefit from noatime on the others? can we use noatime if we just don't use ETRN?
  • filesystem can be mounted nodev,noexec,nosuid - no* won't prevent you from setting attributes (postfix uses exec attr) they just won't have any effect (we don't run anything from the spool)
  • the fsync() issue cited by Wietse and/or the chattr -S are probably linked to sync/async options of ext3fs but I do not understand them enough. Mouting the filesystem with async option is equivalent to chattr -R -S the whole fs? Seems like it will increase performance, but will that pose a risk of "loss of mail after a system crash" or is it really "safe on /var/spool/postfix" ?
  • would you tune anything else on postfix-2.6.x to work better on ext3 or do you leave defaults everywhere?
  • is there a "best" linux I/O scheduler for this kind of workload (namely CFQ or deadline?) or that's something that will vary too much based on hardware configuration?
  • would you tune anything else in the filesystem or in the kernel?
  • anything else?

References:

  • Postfix Performance here on SF
  • Postfix documentation about the Incoming Queue
  • Wietse Venema in Best file system on postfix-users@postfix.org here
  • Postfix and ext3 on ext3-users@redhat.com here and there
Community
  • 1
Luke404
  • 5,708
  • 3
  • 44
  • 58
  • I share a lot of these same questions. It'd be best to ask Wietse what he thinks. I can say from experience that mounting the entire `/var/spool/postfix` volume with `noatime` hasn't caused noticeable issues with queuing (AFAIK). 99.999999% are `status=sent`. Our mount line used on production mail servers (which process ~200Mil messages/month) is: `/dev/xvdf /var/spool/postfix ext4 rw,seclabel,noatime,data=ordered 0 0`. FS=`ext4`, bytes/inode=`4096` (`mkfs.ext4 -T news`). A very small % of emails (0.0000008%) get stuck in `deferred` queue/month. To fix, run: `postqueue -f` – TrinitronX Aug 16 '19 at 20:42

1 Answers1

2

Given the specific nature, I tend to use default settings. In my case, postfix was never really the bottleneck and I and I spent most of my time tuning AntiSpam/AntiVirus/MDA.

Rianto Wahyudi

Rianto Wahyudi
  • 493
  • 3
  • 11
  • Agree. Instead of tuning ext3 probably you'll get much better performance just change the file system. But as said, most of the time the bottlenecks of a mailing system is not the smtp daemon but all the other apps running together with it. One of the most increase in speed i got it running amavis tmp in a ram disk. – PiL Jun 16 '10 at 11:01
  • 1
    I appreciate your suggestions, but the mail scanning stuff is entirely another story and not the topic here. When you start to grow traffic on your mail server, the content scanning is usually on different hosts than the edge Mail eXchangers. They also tend to have entirely different problematics when getting to performance optimizations. – Luke404 Jun 16 '10 at 12:09
  • If the traffic grows, you just add more server ( eg postfix+antispam) I don't see the point of having different host doing just content scanning. Passing mail to different host require additional transport method which increase latency & complexity ( eg mail has to be sent to the scanning host , scanning host has to accept, queue & verify that the mail has been accepted, scan the message and notify the sending server if the mail is spam or virus). – Rianto Wahyudi Jun 17 '10 at 09:29
  • Keeping things as simple as possible allows you to add more servers quickly. With mail server, having 2 less powerfull server is better than having 1 powerfull server. If you manage more than 10 inbound SMTP servers, the performance vs benefits of configuring every little detail is just not worth the time. Linux & postfix also getting better everytime and further down the road you probably dont need to do these tweaks ( example of this is tuning shmax kernel parameters) – Rianto Wahyudi Jun 17 '10 at 09:48