On 21/04/2018 8:07 AM, Ram wrote:
On 04/21/2018 05:32 PM, Ron Wheeler wrote:
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
If you look at a system monitor output (top on Linux is enough), is
Postfix using 100% of the CPU? Is there a significant amount of
process time in wait queues? Is there lots of spare physical memory?
Probably a silly question but are you sure that the sending
application or network is not the bottleneck?
If you configure Postfix to throw away the e-mails immediately in
receipt does the inflow meet your expectations.
I thought so too.
I tried using postfix-sink and the mails are sent at max speed. So the
network is not a problem
https://netcore.in/20-years-journey/?utm_source=email-disclaimer&utm_medium=email&utm_campaign=netcore-turns-20
Does the analysis of which postfix tasks are eating the CPU give any hints?
Ron
--
Ron Wheeler
President
Artifact Software Inc
email: rwhee...@artifact-software.com
skype: ronaldmwheeler
phone: 866-970-2435, ext 102