MIN_TIMER_WAIT field is inconsistent for wait/synch/cond/rocksdb/cond_stop

[maykov]

To repro this, you need to build and run with perf schema enabled.

1.
truncate table performance_schema.events_waits_summary_by_instance; truncate table performance_schema.events_waits_summary_global_by_event_name; select * from performance_schema.events_waits_summary_global_by_event_name where event_name like '%rocksdb%';select * from performance_schema.events_waits_summary_by_instance where event_name like '%rocksdb%';

You will see all zeroes as it should be.

Repeat the select portion of above statements in a few seconds. Values for wait/synch/cond/rocksdb/cond_stop will be much higher. However, MIN_TIMER_WAIT field in the _by_event_name will stay at zero forever, while _by_instance table will reflect the actual minimum wait time.

This causes the perfschema.aggregate test to break.

Few more questions: Why values for cond_stop are so huge ? (eg 1105186494971650) Are they in CPU ticks?
Why do all other rocksdb counters stay at zero?

[maykov]

Example of the failure:
===========
$mysqltest.sh --perfschema perfschema.aggregate --repeat=5
.....
CURRENT_TEST: perfschema.aggregate
--- /data/users/maykov/mysql/5.6/mysql-test/suite/perfschema/r/aggregate.result 2015-07-20 22:21:42.424748049 +0300
+++ /data/users/maykov/mysql/5.6/_build-5.6-Debug-PerfSchema/mysql-test/var/log/aggregate.reject 2015-07-21 02:30:39.323111516 +0300
@@ -86,6 +86,7 @@
HAVING (e.MAX_TIMER_WAIT < MAX(i.MAX_TIMER_WAIT))
OR @dump_all;
EVENT_NAME MAX_TIMER_WAIT MAX(i.MAX_TIMER_WAIT)
+wait/synch/cond/rocksdb/cond_stop 0 1001177278010
"Verifying waits aggregate consistency (thread)"
SELECT EVENT_NAME, e.SUM_TIMER_WAIT, SUM(t.SUM_TIMER_WAIT)
FROM performance_schema.events_waits_summary_global_by_event_name AS e

mysqltest: Result content mismatch

Some observations: innodb doesn't use conditions to stop background threads it is running. Instead, it is running threads like this while (srv_shutdown_state == SRV_SHUTDOWN_NONE) {do stuff}. This is not ideal for us for two reasons:
1. It might break on some machine architecture (which we might never run on anyway)
2. Rocksdb plugin waits for the condition or a timeout. So, the wait doesn't consume CPU and stops right away upon server shutdown.
At this point, moving to innodb way would simplify things but will be a regression.

I think, this bug is not specific to MyRocks but probably somewhere in the server. We do not do anything special with conditions and aggregation counters. I'm going to stop exposing PFS about conditions which will fix this test.

[yoshinorim]

WebScaleSQL disables performance schema by default, so I think it's fine to ignore for the time being.

[jtolmer]

WebScaleSQL and FB-MySQL both intentionally test with PerfSchema enabled in order to make sure that we're not building up a lot of debt of broken functionality.

[spetrunia]

AFAIK, the values are in picoseconds. They are not in CPU ticks, because one can use different timers for measurements (see setup_timers )