Re: Postfix and local mail delivery - still relevant in 2020?

[Johnny Billquist <bqt%update.uu.se@localhost>]

On 2020-06-07 19:35, Greg A. Woods wrote:
> At Sun, 7 Jun 2020 12:46:51 +0200, Johnny Billquist <bqt%update.uu.se@localhost> wrote:
> Subject: Re: Postfix and local mail delivery - still relevant in 2020?
> > On 2020-06-07 07:32, Greg A. Woods wrote:
> > > At Sun, 7 Jun 2020 01:53:34 +0200, Johnny Billquist <bqt%update.uu.se@localhost> wrote:
> > > Is the slow startup you observe happening with just the default
> > > configuration (for local delivery)?
> >
> > It's happening with any kind of configuration.
> >
> > Basically, anything written in C++ is almost a lost cause even before
> > starting.
>
> Do you mean you're under the impression Postifix is written in C++?
>
> Perhaps you should look at the Postfix code -- it's entirely pure C.

D'oh! I could have sworn it was in C++. I looked at stuff back when 
NetBSD switched to it, because the speed difference was so big. Either I 
was totally looking at something wrong back then, or my memory is now 
playing tricks on me, as it's clearly C, yes.

Still horribly slow, though.

> > postfix alone takes close to a minute to get going at boot time on my
> > VAXen...
> > And that is just counting before rc continues to the next item. I
> > haven't checked if postfix are then still being busy actually getting
> > things sorted in the background...
>
> That's very interesting.
>
> The slowest machine I have running at the moment is a little old Soekris
> box, with a FLASH disk as root:
>
> 	# time /etc/rc.d/postfix restart
> 	postfix/postfix-script: stopping the Postfix mail system
> 	postfix/postfix-script: waiting for the Postfix mail system to terminate
> 	postfix/postfix-script: starting the Postfix mail system
> 	    3.31s real     1.21s user     0.76s system
>
> Now that's a little unfair for two reasons.
>
> First off the programs were just running so the good sized parts of
> their text segments were already in memory.
>
> So I stopped Postfix, flushed it from RAM by reading a bunch of big
> files from an attached cache disk and started it again:
>
> 	# time /etc/rc.d/postfix start
> 	postfix/postfix-script: starting the Postfix mail system
> 	    3.29s real     1.08s user     0.77s system
>
> So, that's still pretty fast.
>
> Now the second unfairness is this:
>
> 	# file /usr/libexec/postfix/master
> 	/usr/libexec/postfix/master: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, for NetBSD 8.99.32, stripped
>
> I.e. my whole build is static-linked.
>
> This is perhaps the big problem since the two processes that have to
> start are like this on stock builds:
>
> 	$ ldd /usr/libexec/postfix/master
> 	/usr/libexec/postfix/master:
> 	        -lsaslc.0 => /usr/lib/libsaslc.so.0
> 	        -lcrypto.14 => /usr/lib/libcrypto.so.14
> 	        -lcrypt.1 => /lib/libcrypt.so.1
> 	        -lc.12 => /usr/lib/libc.so.12
> 	        -lgcc_s.1 => /usr/lib/libgcc_s.so.1
> 	        -lssl.14 => /usr/lib/libssl.so.14
> 	        -lgssapi.11 => /usr/lib/libgssapi.so.11
> 	        -lkrb5.27 => /usr/lib/libkrb5.so.27
> 	        -lhx509.6 => /usr/lib/libhx509.so.6
> 	        -lasn1.10 => /usr/lib/libasn1.so.10
> 	        -lcom_err.8 => /usr/lib/libcom_err.so.8
> 	        -lroken.20 => /usr/lib/libroken.so.20
> 	        -lutil.7 => /usr/lib/libutil.so.7
> 	        -lwind.1 => /usr/lib/libwind.so.1
> 	        -lheimbase.2 => /usr/lib/libheimbase.so.2
> 	        -lsqlite3.1 => /usr/lib/libsqlite3.so.1
> 	        -lheimntlm.5 => /usr/lib/libheimntlm.so.5
> 	        -lldap.4 => /usr/lib/libldap.so.4
> 	        -llber.3 => /usr/lib/liblber.so.3
> 	$ ldd /usr/libexec/postfix/qmgr
> 	/usr/libexec/postfix/qmgr:
> 	        -lsaslc.0 => /usr/lib/libsaslc.so.0
> 	        -lcrypto.14 => /usr/lib/libcrypto.so.14
> 	        -lcrypt.1 => /lib/libcrypt.so.1
> 	        -lc.12 => /usr/lib/libc.so.12
> 	        -lgcc_s.1 => /usr/lib/libgcc_s.so.1
> 	        -lssl.14 => /usr/lib/libssl.so.14
> 	        -lgssapi.11 => /usr/lib/libgssapi.so.11
> 	        -lkrb5.27 => /usr/lib/libkrb5.so.27
> 	        -lhx509.6 => /usr/lib/libhx509.so.6
> 	        -lasn1.10 => /usr/lib/libasn1.so.10
> 	        -lcom_err.8 => /usr/lib/libcom_err.so.8
> 	        -lroken.20 => /usr/lib/libroken.so.20
> 	        -lutil.7 => /usr/lib/libutil.so.7
> 	        -lwind.1 => /usr/lib/libwind.so.1
> 	        -lheimbase.2 => /usr/lib/libheimbase.so.2
> 	        -lsqlite3.1 => /usr/lib/libsqlite3.so.1
> 	        -lheimntlm.5 => /usr/lib/libheimntlm.so.5
> 	        -lldap.4 => /usr/lib/libldap.so.4
> 	        -llber.3 => /usr/lib/liblber.so.3
>
> That's an awful lotta libraries to rattle through!  The runtime linker
> isn't terribly fast as it has quite a bit of computation to do, and just
> doing the I/O alone to page in enough of all those files on an older
> machine is going to take quite a long time.

Ah. Maybe this is my misremembering. Maybe I dug through a bunch of this 
when much of the NetBSD core system switched from being statically 
linked to being dynamic. That was definitely a painful moment as well...

> Now I don't know what your storage situation is on your VAXen, but if
> you can possibly afford to static-link your build you'll find things
> start so much faster you'll be VERY surprised.

Good point. At this point I'm willing to think I was just confusing my 
brain about the switch from sendmail to postfix with the switch from 
static to dynamic binaries.

Disk - while I don't have anywhere close to current views of "plenty", I 
have enough to afford static linking.

Regarding your speed measurements, flash in itself already gives you a 
very skewed picture, by the way. I'm all on old, spinning rust when we 
talk these machines...

And much of the time not even on anything like SCSI... So we're talking 
very slow disks by todays standards...

  Johnny

--
Johnny Billquist                  || "I'm on a bus
                                  ||  on a psychedelic trip
email: bqt%softjar.se@localhost             ||  Reading murder books
pdp is alive!                     ||  tryin' to stay hip" - B. Idol