Bug #78526 Fix scheduler to accomodate for longer scan executions

• Submitted: 23 Sep 2015 7:17
• Modified: 5 Jan 2016 15:30
• Reporter: Mikael Ronström
• Status: Closed
• Category: MySQL Cluster: Cluster (NDB) storage engine
• Severity: S3 (Non-critical)
• Version: 7.4.7
• OS: Any
• CPU Architecture: Any

[23 Sep 2015 7:17] Mikael Ronström

Description:
In MySQL Cluster 7.4 we optimised the scan execution by handling multiple rows within one
timeslot. This has an effect on two things. 1) It gives the scan executions higher prio
compared to the key lookup operations. 2) It changes the behaviour of the scheduler loop
effectively making it execute for longer and thus making NDB less responsive.

How to repeat:
Run DBT2 and watch response time of Payment (fair amount of scan) vs NewOrder (PK ops only) transaction.

Suggested fix:
Introduce config variable specifying how many rows to scan per time slot. The higher this one is
set to, the higher the total throughput, but also the higher prio of scans. Lowering will give
key operations a higher prio.

Count each scanned row as one signal execution to make NDB scheduler work similarly as in earlier
versions.

[5 Jan 2016 15:30] Jon Stephens

Fixed in 7.4.9 by adding a __sched_scan_priority parameter for testing purposes. This is currently for internal use only. Closed.