Nigel Kukard <[email protected]> wrote: >> 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.
I couldn't say what the settings were at the time - things have changed since. I probably do need to go back and check the tuning again. >> 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. I was thinking more of : - read fails, so daemon doesn't know there is an existing record (should it know there was a failure ?) - daemon creates new record (it doesn't try an update as it "knows" there isn't an existing record) - new record has count set to 1 So it's really a case of what happens when it adds a new record and one already exists. Depending on how it's coded, I could see it doing any of insert fails, database gets duplicate record, insert overwrites old record, something else ? > > 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 ;) See above, I had a slightly different failure mechanism in mind. _______________________________________________ Users mailing list [email protected] http://lists.policyd.org/mailman/listinfo/users_lists.policyd.org
