Hi, > >Whether you throttle based on queue length or system load, to solve >this problem you need do it *relative to your other servers*. > >If *all* your servers had had long queues that they were successfully >trundling through, throttling on the queue length would have slowed >things down even more. Having this one server stop accepting mail >whilst the queue drains only helps because the others are free. >
Absolutely, and this is something that we are aware of and so we designed our system with 'relative to other servers' in mind from the start (Vmware and multiple small specific purpose hosts are my friends here). Anyway this question has arisen due to a specific incident that happened over the weekend where a single server was having issues internally which resulted in mail being accepted but being unable to actually being able to egress the email through no fault of Exim. Mail as a whole was fine as this component of the service sits as matched pair behind load balancers which distribute the load evenly where there is a response - whence wanting when the queue length gets to a high watermark for SMTP to automatically be disabled to allow things to trundle or at worst case wait where things are in a rare case completely stuffed. That way mail still goes to the matched server and things carry on. Worst case is the very rare circumstance where both are stuffed and mail gets held internally until we look at it. Paul -- ## List details at https://lists.exim.org/mailman/listinfo/exim-users ## Exim details at http://www.exim.org/ ## Please use the Wiki with this list - http://wiki.exim.org/
