Change log_slow_rate_type=query log_slow_rate_limit to be random

Bug #1287650 reported by Laurynas Biveinis on 2014-03-04
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Percona Server
Status tracked in 5.6
5.1
Undecided
Unassigned
5.5
Medium
George Ormond Lorch III
5.6
Medium
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

lp:~gl-az/percona-server/bug1287650-5.5
Alexey Kopytov (community): Approve on 2014-04-25
Laurynas Biveinis: Needs Fixing on 2014-03-06
lp:~gl-az/percona-server/bug1287650-5.6
Alexey Kopytov (community): Approve on 2014-04-25
Laurynas Biveinis: Pending requested 2014-03-05
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