On 21/04/2018 7:38 AM, Ram wrote:
On 04/20/2018 07:39 PM, Wietse Venema wrote:
Ram:
On 04/20/2018 07:14 PM, Wietse Venema wrote:
Ram:
I have a very busy postfix server that acts as a relay. It gets mails
from an application and then forwards the mails to the delivery
servers
on local LAN
The application can send mails at rate of? upto 600 mails per second
Postfix has been configured to accept mails all that quickly, but the
delivery is very poor until inflow stops. Only around 20-50 mails
per s
Once the app completes the inflow, then the mails are cleared at a
rate
of 1000 mails per second
Why ?
Is there a contention on the queue manager when the inflow is too
quick ?
No, there is contention for the file system.
If you disabled in_flow_delay, turn it back on, please. This allows
the queue manager to push back, though it works only for clients
that make few parallel connections.
Otherwise, you need a faster disk. SSDs have become quite affordable,
even the 'enterprise' ones that have some extra capacitors to prevent
data corruption after power failure.
I am using spool dir on /dev/shm
in flow delay .. slows down smtp connections which the application can
not handle
That is why I have disabled
If you can't use the Postfix safety mechanism, then I can't help you.
I know , And in_fllow_delay works for almost all cases where I use
postfix. Excepting when 1 sec delay per process becomes too much
If I have a high end machine , will running multiple postfix instances
on the same machine help
That way If I change the app to deliver to multiple instances
simultaneously.
There is no IO load running everything in /dev/shm
https://netcore.in/20-years-journey/?utm_source=email-disclaimer&utm_medium=email&utm_campaign=netcore-turns-20
I hope that you have no spam or virus checking on the inflow.
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102
