Change log_slow_rate_type=query log_slow_rate_limit to be random

Bug #1287650 reported by Laurynas Biveinis
6
This bug affects 1 person
Affects Status Importance Assigned to Milestone
Percona Server moved to https://jira.percona.com/projects/PS
Fix Released
Medium
George Ormond Lorch III
5.1
Won't Fix
Undecided
Unassigned
5.5
Fix Released
Medium
George Ormond Lorch III
5.6
Fix Released
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

tags: added: slow-extended
Revision history for this message
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)

Revision history for this message
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.

Revision history for this message
Shahriyar Rzayev (rzayev-sehriyar) wrote :

Percona now uses JIRA for bug reports so this bug report is migrated to: https://jira.percona.com/browse/PS-145

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

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.