Milter-greylist

Hi,
 	Today we have seven mx relays and each machine has the other six 
as peers. I often see 10-20 of these each second in my logs:
"
peer IP_for_apeer queue overflow (1024 entries), discarding new entry in 
"

Should we be syncing like this? Would it make more sense to limit peers to 
one or two hosts each and push updates in that way such:

Let each mx relay be labeled a, b, c, d, e, f, and g. Each relay would 
sync with the mx relays on the right hand side:

a -> b, c
b -> c, d
c -> d, e
d -> e, f
e -> f, g
f -> g, a
g -> a, b

Instead of how we do it today:
a -> b, c, d, e, f, g
b -> c, d, e, f, g, a
etc

Thanks!
Jonathan

Jonathan Siegle jsiegle+mg@... [milter-greylist]
<milter-greylist@yahoogroups.com> wrote:

> Hi,
>       Today we have seven mx relays and each machine has the other six
> as peers. I often see 10-20 of these each second in my logs:
> "
> peer IP_for_apeer queue overflow (1024 entries), discarding new entry in
> "

Usually that happens when a peer is down. If this is not the case, you
can raise the limit with syncmaxqlen. 

Your tree diffusion proposal is nice, but it would not be easy to
implement correctly. Moreover I am not convinced you would save any
resource since an entry must always reach every peer. 

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@...

On Fri, Nov 06, 2015 at 09:27:01PM +0100, manu@... [milter-greylist] wrote:
> Usually that happens when a peer is down. If this is not the case, you
> can raise the limit with syncmaxqlen.

IMO it's probably not a good idea to raise syncmaxqlen. Under regular
conditions a sync queue of 1024 is more than enough.

Isn't this an old issue?

Changelog:

  4.1.9
    Workaround "peer queue overflow" bugs (Laurence Moindrot, Jean Benoit)

Best regards

Manuel

On Fri, Nov 06, 2015 at 01:02:32PM -0500, Jonathan Siegle jsiegle+mg@... [milter-greylist] wrote:
> Today we have seven mx relays and each machine has the other six 
> as peers.

BTW if your mail load requires 7 MX. Consider monkey patching PENDING_BUCKETS
in pending.h to a reasonable value. MG uses a static hash table that tends to
overload.


Best regards

Manuel

Manuel Badzong manuel@... [milter-greylist]
<milter-greylist@yahoogroups.com> wrote:

> > Usually that happens when a peer is down. If this is not the case, you
> > can raise the limit with syncmaxqlen.
> 
> IMO it's probably not a good idea to raise syncmaxqlen. Under regular
> conditions a sync queue of 1024 is more than enough.

Well I am not sure of what happens with 7 MX. My first hunch is about a
MX being down or unreachable, though.

-- 
Emmanuel Dreyfus
http://hcpnet.free.fr/pubz
manu@...