On 04/01/2014 06:59 AM, Simon Hobson wrote:
Nigel Kukard <[email protected]> wrote:
On 03/31/2014 10:47 PM, Simon Hobson wrote:
Nigel Kukard <[email protected]> wrote:
I'm just wondering if there's a race condition where multiple servers are
updating the quota, and one update overrides another ?
I believe the updates are done += and -= style with the delta, not updating
the actual value with value = x
ref:
https://gitlab.devlabs.linuxassist.net/policyd/policyd/blob/master/cbp/modules/Quotas.pm#L269
Rules that one out then.
Hrmmm, were you using any sort of replication ... then again, even if you were
the updates are still += , hrmm ... that and MySQL afaik uses statement
replication, not row
Originally I was running a single PolicyD and MySQL server on the backend.
Apart from some performance problems (which were the subject of a thread on
here at the time), PolicyD never gave any problems. It was the Postfix access
to the DB that gave problems - a lot of lookups for Postfix Admin.
Do you have query cache enabled? On some installations we'd had to give
it quite a substantial amount of RAM to get optimum results.
Another thought does come to mind for the OP's problem. What happens if PolicyD
fails to retrieve a quota tracking record ? I'm guessing it creates a new one -
if one exists when a new one is added, does the old one get removed first, or
updated to the new values, or ... ?
It tries an update first, if that fails an insert, if that fails
(extremely rare due to DB clash) the mail is deferred as a DB error
(failed insert) occurred.
What I'm thinking is if there are random lookup failures, eventually one frontend fails
to retrieve a record so it "adds" a new one - resetting the quota to 1 when it
does so.
I don't think duplicates are possible, maybe the OP can check if he only
see's 1 entry in the DB. The process of updating should really not be an
issue, when we changed from value = new_value to value += delta we
tested exactly this in some very large setups to fix this exact issue ;)
-N
_______________________________________________
Users mailing list
[email protected]
http://lists.policyd.org/mailman/listinfo/users_lists.policyd.org
