Details
-
Bug
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
13.0.1
-
None
-
Related to performance
Description
Performance Schema overhead is not fixed and can vary depending on how the client workload is executed. In testing, enabling Performance Schema affected stored procedures more heavily than client-side SQL, changing the relative comparison between the two.
Test results:
| Performance Schema | Stored procedures NOPM | Client SQL NOPM |
|---|---|---|
| ON | 454,061 | 456,629 |
| OFF | 599,787 | 501,499 |
With Performance Schema enabled, stored procedures and client SQL produced almost the same throughput. With Performance Schema disabled, stored procedures were 19.6% faster than client SQL.
The impact was not uniform. Stored procedure throughput increased by 32% with Performance Schema disabled, while client SQL increased by 10%. This shows that Performance Schema can unevenly affect performance comparisons depending on the application, rather than adding a single expected overhead.
The wait profile also changed. With stored procedures enabled, wait/synch/mutex/sql/THD::LOCK_thd_data accounted for up to 47% of observed DB time. Without stored procedures, the same wait was approximately 15%.
The test was also run with wait-event monitoring enabled and disabled. This did not change the relative throughput results, so the performance difference does not appear to be caused by the monitoring queries themselves. However, without monitoring enabled it is not possible to confirm whether the THD::LOCK_thd_data wait profile is exactly the same.
Attachments
Issue Links
- relates to
-
MDEV-33181 Performance schema introduces many conditional branches even when disabled at runtime
-
- Open
-