Details
-
Bug
-
Status: Stalled (View Workflow)
-
Major
-
Resolution: Unresolved
-
10.11, 11.4, 11.8, 12.3
-
Related to performance
Description
rahulraj mentioned that he observed a significant performance regression on a development version of MDEV-37949 when PERFORMANCE_SCHEMA is enabled. I thought that it would be a useful experiment to disable the PERFORMANCE_SCHEMA instrumentation on log_sys.latch along these lines:
diff --git a/storage/innobase/include/log0log.h b/storage/innobase/include/log0log.h
|
index 64f0eabb23f..d5a0e5812be 100644
|
--- a/storage/innobase/include/log0log.h
|
+++ b/storage/innobase/include/log0log.h
|
@@ -202,7 +202,7 @@ struct log_t
|
bool latch_have_rd() const { return latch.have_rd(); }
|
bool latch_have_any() const { return latch.have_any(); }
|
#else
|
- typedef srw_lock log_rwlock;
|
+ typedef srw_lock_low log_rwlock;
|
# ifndef UNIV_DEBUG
|
# elif defined SUX_LOCK_GENERIC
|
bool latch_have_wr() const { return true; } |
perl -i -pe 's/(log_sys\.latch\..._lock)\(SRW_LOCK_CALL\)/$1()/g' storage/innobase/fil/fil0fil.cc storage/innobase/fsp/fsp0sysspace.cc storage/innobase/handler/ha_innodb.cc storage/innobase/log/log0log.cc storage/innobase/log/log0recv.cc storage/innobase/mtr/mtr0mtr.cc storage/innobase/row/row0mysql.cc storage/innobase/srv/srv0* extra/mariabackup/xtrabackup.cc
|
Some further removal of SRW_LOCK_CALL in some log_t member functions is necessary to make the code compile. For a quick Sysbench experiment on top of MDEV-38968, this experiment improved the throughput by 2.9%.
I would not expect any benefit from any PERFORMANCE_SCHEMA instrumentation of log_sys.latch. The few code paths where an exclusive log_sys.latch is being held cannot be improved easily. The code paths that are covered by a shared log_sys.latch should already be optimal ever since MDEV-21923 was fixed.
Attachments
Issue Links
- relates to
-
-
- Closed
-
-
MDEV-37949 Implement innodb_log_archive
-
- In Review
-
-
-
- Closed
-