I use postfix to do final delivery for a mail system I've written. So this postfix installation only accepts mail from me, and bounces. When the postfix queue is empty, it can accept a piece of mail in 5ms or so. When the queue has 150k-200k messages or so, the handoff speed from me to postfix is really slow, like 50-100 sometimes 500ms.
I have log times on every piece of the SMTP conversation, so I can see where the time is going. Some of it is when I'm waiting for a response from the RCPT TO command, but the vast majority of the time disappears after I send the final dot, before I get the "250 okay queued as..." response.
I'm thinking maybe the RCPT TO delay is in a DNS lookup, but that doesn't help me with the queuing time. I keep one TCP socket open for all the email I'm sending, and I RSET the conversation for each mail, so there's no time lost to making and breaking TCP connections, it's all waiting for postfix to queue the message.
Everything I've read about performance tuning postfix has to do with queue management and sending mail for this and that domain here and there. But I'm concerned with getting postfix just to accept the mail quickly in the first place.
Is there any way to find out what postfix is doing with all this time or is there a way to make it go faster? The /var/spool/postfix queue is on local disk, so I can't make that any faster.
Any suggestions?
Set the following in
main.cfThis produces subdirectories in the incoming and active queues so that the flat directories don't contain all mails at once. They are now put into subdirectories.
But note: Having 150k-200k messages waiting for delivery shows an incredible wrong understanding of a balanced sending of mails. This looks like spamming to me...
One of the solutions was to have a secondary mail server that handles all the bounces that are waiting to be delivered, this was the best solutios to keep the real email going through.