Klaus Alexander Seistrup wrote the following on 12/14/04 19:38 :
>Hi,
>
>SQLgrey relies on quite a few time related variables --
>reconnect-delay, max-connect-age, awl-age, and others -- but unless a
>commented configuration fils is used, there is no way of knowing the
>time unit of a given variable. E.g., the re-connect-delay takes
>minutes, the max-connect-age takes hours, the awl-age takes days, and
>so on...
>
>To make the values more intuitive, I suggest that times be given by
>appending specific units (e.g. w=weeks, d=days, h=hours, m=minutes,
>s=seconds), and that SQLgrey converts to whatever unit it uses
>internally (seconds?). Composite values should be possible, e.g.
>10m11s == 671 seconds.
>
>
Wow, my TODO list is under siege... But you are right, this can become
confusing and adding units is a good solution.
Do you *really* need composite values ? It's not a big deal, but will it
serve a purpose ? For example I can't imagine 10m11s being more useful
than 10m or 11m.
>Btw, my mx is running SQLgrey 1.4.0. This version uses a variable,
>maint_delay, for controlling when to do household cleaning. However,
>the default value is 0 (seconds), meaning that cleanup is trigerred by
>each mail that arrives. On a busy site this might not be optimal, but
>the value doesn't seem to be configurable...
>
>
>
Yep. I forgot to make this configurable. I realised this after 1.4.0.
"0" doesn't seem to be a problem on most sites, but it should definitely
be configurable and documented as this variable is a tradeoff between :
- delaying spam reports in logs (increasing maint_delay delays the reports),
- more stressfull cleanups (and SQLgrey is waiting on each cleanup to
complete wich can make this a real problem) when maint_delay increases,
- mean load increase when maint_delay is low.
There's no magic solution but here is what I'm considering :
- make maint_delay configurable and let the DBA tune it and leave this
nasty optimisation problem to her/him,
- make cleanup an independant process forking from the main SQLgrey
process using heuristics to fine tune the delay between cleanups (ie:
don't lower the delay under a given value, don't make it higher than
another, try to reach an average cleanup time of less than a third value
without making it reach an average cleanup time of more than a forth on
a given hour period), that will probably mirror what a DBA will try to
do but make it automatic (did I mention bloat in a previous e-mail ? :-)).
- switch to Net::Server::Prefork in order to stop blocking, there are
numerous downsides though (code complexity, concurrent database accesses
that will slow it down, connections refused when the server reachs its
children limit, ...).
There's another problem with cleanups : how should SQLgrey handle them
when multiple SQLgrey instances use the same database. I have some ideas
like storing a last_cleanup timestamp in the new "config" table to make
it easy to distribute among them.
Lionel.
|
