[rt-users] Throttling incoming e-mail

[Les Mikesell]

On Sun, 2005-08-21 at 18:07, Kevin White wrote:
> Hello:
> 
> We're using RT 3.4.1 for our internal trouble ticket system
> 
> We have several monitoring programs doing SNMP monitoring.  When they
> detect problems, they generate an e-mail, which hits the RT box, which
> hits sendmail, then an alias that hits rt-mailgate.  We also have a
> scrip (ExtractCustomFieldValues, from the Wiki) running that populates
> custom fields (so the body of the messages are parsed).  The messages
> are short.
> 
> But there can be lots of them.  Which tends to kill the box: memory
> exhaustion.
> 
> The problem is, lots of messages come in at once, sendmail obliges, and
> forks off an rt-mailgate for each one, and then moves on.  Even
> throttling sendmail (telling it to only accept x messages concurrently)
> causes the problem, because sendmail just forks off the rt-mailgate and
> goes on.  It only launches x at a time, but it doesn't care that x! are
> still running.  :)
> 
> So, I'm wondering if anyone else has this problem.  I see several
> solutions.  One would be to see if there's any way I can make sendmail
> actually WAIT for the rt-mailgate to finish.  If anyone out there knows
> how to do that, that would be nice (and might be nice to put in the Wiki
> too).  Barring that, I'm seeing a real queue mechanism, where sendmail
> just receives all the mail and saves it (possibly in a maildir, so I can
> process them one at a time easier) and I'll use that as a queue, and
> right a queue processor that submits those one at a time to rt-mailgate.
>  Has anyone written anything like that?  If not, well, I'll probably be
> announcing it at some point in the future.  :)


If you change
O DeliveryMode=background
to
O DeliveryMode=queued 
in sendmail.cf, sendmail will queue all messages when received instead
of starting a background delivery process for each.  However, then you
move the problem to the queue runs - if you start them often enough to
get timely delivery you may have several overlapping runs if they
can't process the whole queue before the next one starts.  You might
set sendmail's timer based runs to go less frequently and have a
script that starts a run with only a short delay after the last one
finishes.

You can also have sendmail queue only when the load reaches a certain
level - and it can take the value in the Precedence: header into account
when deciding when to queue.

--  
  Les Mikesell
    les at futuresource.com