|List:||Commits||« Previous MessageNext Message »|
|From:||He Zhenxing||Date:||November 26 2009 6:44am|
|Subject:||Re: bzr commit into mysql-5.1-bugteam branch (Dao-Gang.Qu:3192)|
|View as plain text|
Andrei Elkin wrote: > After sleeping, and sleeping on this matter I think we would agree on > > 1. Rating for the error log should be done per session Bug#42851 is about limiting **warnings** written into error log, error messages will not be affected by this. So I think it's not necessary that we need to make sure that every session got a chance to output it's warnings. I think a global limitation over all warnings generated by the server is good enough. > 2. Rating should target at duplicate messages Remove duplicated messages can reduce messages written into the error log, but this can not solve the problem of bug#42851, we still need a way to limit the total numbers of warnings going into error log within a interval. And I think the mechanism to remove duplicated messages should be done for all kinds of messages written into error log, not just warnings. > > Per implementation, I still think the numeric id, not a checksum is the key that > should be associated > with the number of hits. That is because many of the messages have variable body. > Expiration logics can be borrowed from the submitted patch. > > Technically rate_limit_impl() could be extended with maintaining a private to > THD of the session the-mess-id-number-of-hits hash. > > cheers, > > Andrei > > > > > Dao Gang, Davi, Serge, hello. > > > > > The patch introduces the global limit whereas a limit per session might be > a better > > solution. > > The global limitting has a drawback that if for instance two connectons > try logging > > the limit value can be hit by the first-and-only error message of the 2nd > session. > > Therefore the error-log observer would miss that 2nd session error > message. > > > > Was that really disscussed before? > > Yes. We have discussed it. The 'a limit per session' solution will make the > volume of messages become uncontrollable, because the number of session is > inconstant. > > But it's still limitted (let's call that C_max). Hence, if your two parameters > applied in the session scope > > --session-log-warnings-ratelimit-interval = 10 > --session-log-warnings-ratelimit-burst = 5 > > thier accumulative effect would be roughly the same as > > --server-log-warnings-ratelimit-interval = 10 > --server-log-warnings-ratelimit-burst = 5 * C_max > > but with the obvious advantage in that all sessions will contribute to the log. > Another advantage is in that the sessions can be discriminated on the basis of the > parameters. > > The above approach does not cover a concern that all messages needs presenting in > the log, at least one time. > If we set up our goal that way then discussion that Sergei and Davi held on #dev > today > could guide us to the solution. > Let me note here, that checksumming of the message can be replaced by > the warning numeric id which is cheap computatioan-wise but would force > us to enumerate all warnings that exist without ids.