On Fri, 2019-02-15 at 20:42 +0100, Christopher R. Gabriel wrote: > > > > Is the "delay" recorded in a typical Postfix log entry ? > > > > Stolen from Postfix 2.3.19: > > > > Postfix logs additional delay information as "delays=a/b/c/d" > > > > where a=time before queue manager, including message > > transmission; > > > > b=time in queue manager; c=connection setup time including > > DNS, > > > > HELO and TLS; d=message transmission time. > > > > > > yes, that's from where I get such data from, like > > > > > > delay=31, delays=30/0/0.33/1.1, > > > > Can you strace the opendkim process? Is it hanging in DNS lookups? > > > > Wietse > > It's in signing mode only, and we I try to strace it (with follow > option for thread) it crashes.
After being able to spend sometime doing perf and strace on the opendkim process, I was able to find out that the underlying NSS stack configuration (nscd + nslcd) was causing the bottleneck. After removing the cache and the LDAP backend (which is a default, but fortunately not mandatory for us), delays got aligned with servers using the old stack (postfix 2.x etc). So they're really to blame, by now I was able to remove the cause of the symptom (semi cit.) Is anyone running the same nss stack without problems? Christopher
