Re: [exim] overall rate limiting?

Pàgina inicial
Delete this message
Reply to this message
Autor: Peter D. Gray
Data:  
A: listrcv
CC: exim-users, Peter D. Gray
Assumpte: Re: [exim] overall rate limiting?
On Wed, May 24, 2006 at 03:00:11PM +0200, listrcv@??? wrote:
> > On Tue, May 23, 2006 at 03:32:03PM +0200, H. Wilmer wrote:
> >> Peter D. Gray wrote:
> >>
> > But when the mail gets to the stores, they kind of
> > get slow. It would be nice if the smtp system on the
> > mail stores knew its own limits and only accepted
> > email at a rate it can handle, but that is not the case.
>
> You mean the mail cannot be written to disk fast enough? What happens in
> that case? I would just expect that this would result in an overall
> slowdown until the spike has been handled.
>


It is not just a question of disk r/w rates.
The stores do all sorts of stuff and have
some bottlenecks.

> For example, if I have a 1.5 GB file in memory and want to write it to a
> disk, the disk might handle 40 MB/sec, so it will just take some time to
> write the file, and the process doing it will have to wait.
>
> Wow, you would have to have an internet connection with quite some
> bandwidth for the storage system to be a bottleneck!
>


Not just that, if a message arrives to
1000 recipients, the stores have to do a bit of work
to make that delivery, even if the message itself
is small.


> > I am routinely seeing mail rates of 60 per second
> > for minutes at a time now, mainly spam.
>
> Hm, can you deploy better SPAM protection?
>


We do greylisting and tagging already.
And I am considering freezing all messages with
UCE scores higher than N and then thawing them at night.
Has anybody else done this?

> Otherwise, you could use _slower_ machines to run exim on. Thus, you will
> get higher load averages on them and use that to keep the data flow below
> what the storage can handle :)
>


Funny you should say that, my hubs are quite slow
and I like them like that for exactly this reason.
But even a slow machine can route a lot of email.

Regards,
pdg

--

See mail headers for contact information.