Hi,
I look after a SAAS site where customers can send emails to their own
domains. At times some of our customers can initiate sending of large mail
volumes - which can swamp the active queue.
>From [1]:
"The only way to reduce congestion is to either reduce the input rate or
increase the throughput. Increasing the throughput requires either
increasing the concurrency or reducing the latency of deliveries."
I thought that reducing TRANSPORT_recipient_refill_limit and
TRANSPORT_recipient_limit would prevent messages sent to the customers
domain from dominating the active queue / prevent blocking of other
customers / backup messages in the incoming queue. To test this, I setup a
new dedicated server, set default_recipient_refill_limit=50 to match the
rate at which this domain accepts messages and default_recipient_limit to
1000. I then directed the customer's traffic to that instance.
The dedicated server was only intended to be used to identify the config
required for a new transport to be implemented on the existing Postfix
instances.
>From my monitoring (Check_MK) I saw that there were still spikes where
messages were added to the active queue faster than 50/5 per second and the
active queue grew to and plateau'd at 20000.
(Specifically I'm using Postfix 2.10 on AWS2 Linux - which is very like
RHEL7).
Have I misunderstood the effect of *_recipient_refill_limit and
*_recipient_limit?
Is there a more appropriate way I can enforce some fairness on the active
queue?
(I also asked about this on Serverfault [2] but have not had any useful
feedback there).
{1] https://www.postfix.org/QSHAPE_README.html
[2]
https://serverfault.com/questions/1155772/postfix-cant-limit-active-queue
TIA
Colin
--
-----BEGIN GEEK CODE BLOCK-----
Version: 3.1
GCM d s+:+ a+ C+++(---)$ UL+++ P+(--) L+++ E--- W+++ N++ w-- PS++(+++())
t+ 5+ X R- tv-- b++ DI++ D e+++ h----
------END GEEK CODE BLOCK------
_______________________________________________
Postfix-users mailing list -- postfix-users@postfix.org
To unsubscribe send an email to postfix-users-le...@postfix.org
