On 2013-10-29, Viktor Dukhovni <exim-users@???> wrote:
> On Tue, Oct 29, 2013 at 05:01:05PM +0000, Jeremy Harris wrote:
>
>> On 29/10/13 16:19, Osborne, Paul (paul.osborne@???) wrote:
>> >I have checked through the manual for the version we are running 4.72
>> >(Debian - squeeze) and cannot see an option like:
>> >
>> >smtp_queue_size_backoff
>> >
>> >Where Exim does not respond to SMTP if there are X no of mails in its own
>> >queue waiting to be processed.
>> >
>> >Is there such an option, if so what is it? If there is not can I add it
>> >as a feature request? :)
>>
>> RFEs can always be opened at http://bugs.exim.org/
>> For your immediate needs, I'd suggest putting some custom stuff onto
>> your smtp connect ACL, involving a ${run } expansion to evaluate
>> the queue size.
>
> With a cache of the count that is updated periodically, rather than
> every time it is queried. Scanning the queue counting messages
> can be I/O intensive. You don't want to do that on every incoming
> SMTP request. You probably also want a high/low watermark strategy
> so that once the count exceeds the high mark, the throttling
> continues until it drops below the low mark.
It's not that I/O intensive, (usually the directory blocks get cached
in RAM) but if you expect more than one connection per minute it may make
sense to run the following as an every-minute cron job
find /var/spool/exim/input -type f -name '*-D' | wc -l > /var/spool/exim/queuesize.tmp && /var/spool/exim/queuesize.tmp /var/spool/exim/queuesize
and use ${readfile: /var/spool/exim/queuesize} to query the size.
there's a race condition: you may want to test what happens if the
file is unreadable (during the mv operation)
--
For a good time: install ntp
