On Fri, 2019-01-04 at 10:26 -0500, Viktor Dukhovni wrote: > > On Jan 4, 2019, at 10:04 AM, Christopher R. Gabriel < > > christopher.gabr...@gmail.com> wrote: > > > > > Or some tables you're using in cleanup are slow. > > > > I only have a header_checks table with 1 single rule to log a > > specific > > header, and a transport map redis-based. Exactly the same > > configuration > > I have on postfix 2.x. > > Cleanup does perform transport lookups. Is redis performing well?
Yes, blazing fast. It's shown in the full log of the smtp session, al the whole transaction (until the reported slowness event) is immediate. > > > The verbose logging does not help, it puts pressure on the > > > filesystem... > > > > I've enable the verbose logging only for debug pourposes, I find > > the > > same behaviour even with logging disabled. > > Well, since cleanup is slow, move the verbose logging to cleanup if > you can't determine why cleanup is blocked more directly. I'll try this too. > Cleanup performs transport lookups, canonical and virtual rewriting, > header/body checks, writes and syncs the message to disk, and > sends a 1-byte notice to the queue manager socket. With inflow_delay > it also waits that long to receive a token from the queue manager. in_flow_delay is default, like in the other postfix 2.x instances, all data (both new and old server) is on ramdisk.. I'll dig into the verbose log for cleanup, hoping to find the problem
