[Sqlgrey-users] Re: Strange sqlgrey behaviour

[Lionel B. <lio...@bo...>]

Alexey Grigoriev wrote the following on 10/18/04 16:55 :

> Hello. I had no time to prepare debian packages this weekend but found 
> some strange feature in postgrey behaviour.
> My question is: When does sqlgrey clear his connection cache? At 
> startup? I've got a lof of records in a connect table. And they 
> disappear only after restarting sqlgrey.
>
I just read my sqlgrey logs and found no problems. But I understood one 
thing : by setting the cleanup to run roughly once a day, I allow 
entries to remain in the connect table for roughly 2 days (the maximum 
reconnect delay is set to 24 hours and the cleanup is done every day : 
the maximum time is the sum, 2 days).

So the number of entries in the connnect table may have go way up 
because of the new default settings.

You can check for stale entries by doing the following query :

PostgreSQL :
SELECT * from connect WHERE first_seen < now() - INTERVAL '2 DAY';

MySQL :
SELECT * from connect WHERE first_seen < now() - INTERVAL 2 DAY;

SQLite :
SELECT * from connect WHERE first_seen < {value} - 172800;

where value is the ouput of
perl -e 'print time . "\n"'

Alexey, if you have entries returned by the above query and your 
settings are the defaults, there's a bug in SQLgrey (or you didn't have 
incoming SMTP connections since ages, as sqlgrey can only clean if 
called by postfix now).

Hint :
If you want to have an estimation of the number of entries in the 
connect table vs different sqlgrey settings, you should :
a: take the mean number of entries in connect with your settings,
b: compute (max_reconnect_delay + cleanup_delay) / 2 (where 
cleanup_delay is now hard-coded to 24 hours), it will give you the 
average delay between a blocked spam and the cleanup of the connect entry,
c: compute the same value above for the settings you would want to try

a x (c/b) will give you the number of entries in connect you should expect.

Best regards,

Lionel.