Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Cannot Reproduce
-
10.0.15
-
None
Description
I can see 2% performance drop in 10.0.15 compared to 10.0.14. This seem to be caused mainly by this revision:
revno: 4500.1.26 [merge]
|
committer: Sergei Golubchik <sergii@pisem.net>
|
branch nick: 10.0
|
timestamp: Thu 2014-11-20 17:05:13 +0100
|
message:
|
XtraDB 5.6.21-70.0
|
At least reverting it helps.
Tracking it further down I can see that this regression comes from upstream revision:
revno: 6119
|
revision-id: bin.x.su@oracle.com-20140819071006-qq5nsq3nkqytml4w
|
parent: sujatha.sivakumar@oracle.com-20140819042708-rx1r6q8ng1pgf9dq
|
committer: bin.x.su@oracle.com
|
branch nick: mysql-5.6
|
timestamp: Tue 2014-08-19 15:10:06 +0800
|
message:
|
Bug#18477009 - INACCURATE HANDLING OF SRV_ACTIVITY_COUNT
|
|
|
We call srv_active_wake_master_thread() directly and one of the places is
|
innobase_commit (and prepare as well). This call not only wakes up the
|
master thread but also increments the srv_activity_count which tells
|
the page_cleaner that server is not idle. That's no what we expect.
|
|
|
We should call srv_active_wake_master_thread() only after the commitment
|
of a write trx, but not read-only trx, or after a rollback. This patch also
|
changes some call of srv_active_wake_master_thread() to
|
ib_wake_master_thread().
|
|
|
Original patch is provided by Inaam.
|
|
|
rb#5909, approved by Jimmy.
|
Specifically think hunk:
=== modified file 'storage/innobase/handler/ha_innodb.cc'
|
--- storage/innobase/handler/ha_innodb.cc 2014-08-02 07:51:08 +0000
|
+++ storage/innobase/handler/ha_innodb.cc 2014-08-19 07:10:06 +0000
|
@@ -3584,10 +3584,6 @@ innobase_commit(
|
|
|
innobase_srv_conc_force_exit_innodb(trx);
|
|
|
- /* Tell the InnoDB server that there might be work for utility
|
- threads: */
|
- srv_active_wake_master_thread();
|
-
|
DBUG_RETURN(0);
|
}
|
Attachments
Issue Links
- relates to
-
MDEV-6478 MariaDB on Power8
-
- Closed
-
Activity
Interesting, is that hunk the reason for slowdown really, removing something makes it slower ? That we can fix.
With this hunk:
[ 90s] threads: 160, tps: 32305.67, reads/s: 452285.98, writes/s: 0.00, response time: 5.21ms (95%)
|
[ 100s] threads: 160, tps: 32584.20, reads/s: 456166.93, writes/s: 0.00, response time: 5.20ms (95%)
|
[ 110s] threads: 160, tps: 31983.60, reads/s: 447774.85, writes/s: 0.00, response time: 5.22ms (95%)
|
If I revert just this hunk:
[ 100s] threads: 160, tps: 33627.49, reads/s: 470789.30, writes/s: 0.00, response time: 5.09ms (95%)
|
[ 110s] threads: 160, tps: 33585.80, reads/s: 470202.75, writes/s: 0.00, response time: 5.10ms (95%)
|
[ 120s] threads: 160, tps: 33635.39, reads/s: 470883.80, writes/s: 0.00, response time: 5.09ms (95%)
|
If there is not a big regression for read-write performance, you have my permission to add those lines back.
Reverting just this hunk will most probably make DML statements to wake waiters twice. Not sure if that'll affect performance, but it sounds excessive at least.
Questions to answer are:
- what's wrong about calling srv_active_wake_master_thread() for read-only queries?
- why not calling it introduced performance regression?
Read only workload is not that important compared to read-write workloads. You may change that but please test read-write performance also.
Couldn't reproduce it again. The only notable change I can think of is that Advance Toolchain was upgraded on the build host. Couldn't find this problem by code analysis either.
Last run numbers:
10.0.15-power (+7200): 34475
|
10.0.15-power (-7200): 34487
|
10.0.16-power (+7200): 34570
|
10.0.16-power (-7200): 34517
|
10.1 (+7200): 33359
|
10.1 (-7200): 33314
|
Jan, please check what we can do about it.