Change log_slow_rate_type=query log_slow_rate_limit to be random

Bug #1287650 reported by Laurynas Biveinis on 2014-03-04
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Percona Server
George Ormond Lorch III
George Ormond Lorch III
George Ormond Lorch III

Bug Description

The current implementation of the log_slow_rate_type=query log_slow_rate_limit feature logs every nth query deterministically instead of each query having a 1/n probability to get logged. This results in very non-uniform filtering for single-threaded or other kinds of uniform workflow. The proper filter should be every query getting 1/nth chance of getting logged.

This will cause some MTR testcases to test less due to reduced slow query log determinism. That's OK.

Related branches

tags: added: slow-extended
George Ormond Lorch III (gl-az) wrote :

So Laurynas, do you think changing the "thd->thread_id % thd->variables.log_slow_rate_limit" test to something like "thd->thread_id % thd->variables.log_slow_rate_limit != rand() % thd->variables.log_slow_rate_limit" would be acceptable?

There are other ways but this would yield a non deterministic actual rate. Over the long haul the real output rate would certainly approximate the desired rate but it would not be a guarantee that "one in every log_slow_rate_limit queries will be logged", i.e. if log_slow_rate_limit is set to 100, there is no absolute guarantee that in 100 queries, exactly one will be logged.

Another way would be to keep some extra value and do something like:

static somevalue = rand() % log_slow_rate_limit;

if( thd->thread_id % thd->variables.log_slow_rate_limit == somevalue)

George Ormond Lorch III (gl-az) wrote :

gahh...sorry about that...somehow hit save...nevermind on that last portion. Just curious about if you think a slightly 'fuzzy' type calculation like mentioned above would be acceptable or if a more deterministic approach is necessary. Thanks.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers