Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.1.6, 10.2.0, 10.3.0, 10.4.0, 10.5.0
-
None
Description
Data comes from Sandy Bridge system running sysbench OLTP RO in 1 thread against 1 table.
Call graphs:
- 0.14% mysqld mysqld
|
- wsrep_on
|
+ 28.85% ha_innobase::general_fetch(unsigned char*, unsigned int, unsigned int)
|
+ 26.34% handler::ha_index_next(unsigned char*)
|
+ 19.48% handler::index_read_idx_map(unsigned char*, unsigned int, unsigned char const*, unsigned long, ha_rkey_function)
|
+ 13.60% ha_innobase::index_read(unsigned char*, unsigned char const*, unsigned int, ha_rkey_function)
|
+ 9.40% handler::ha_index_read_map(unsigned char*, unsigned char const*, unsigned long, ha_rkey_function)
|
+ 2.15% innobase_commit(handlerton*, THD*, bool)
|
wsrep_on() is the one defined in wsrep_mysqld.cc. Most time spent for function call convention. I guess all calls come from InnoDB. Either call WSREP() or cache wsrep_on() value.
Attachments
Issue Links
- causes
-
-
- Closed
-
- relates to
-
-
- Closed
-
Activity
Quoting some of my analysis from MDEV-22203:
The macro WSREP_ON used to be defined simply as an alias the global Boolean variable global_system_variables.wsrep_on. A more complex variant that invokes strcmp was introduced, in
MDEV-16799renamed to WSREP_ON_NEW, and related toMDEV-16405(Galera 4) in 10.4.2 the more efficient macro WSREP_ON was replaced altogether.
The calls to the non-inlined function wsrep_on() were introduced in MariaDB Server 10.1.6 (and in the separate 5.5-galera and 10.0-galera products earlier). Could we replace that function with the macro invocation WSREP_ON and make that macro more efficient, as requested in MDEV-22203?
I pushed some cleanup to 10.4 to add some short-circuit evaluation before invoking the function. This was a follow-up to MDEV-22203, which introduces a global variable to speed up WSREP.
As far as I can tell, the reason why the function wsrep_on() exists is that THD is an opaque type for InnoDB, and thus the equivalent macro WSREP(thd) is unavailable to InnoDB. Could we use some other mechanism for this, such as caching the value in innobase_trx_init()?
Also, why does the file sql/wsrep_dummy.cc exist?
I will fix this by caching the attribute in trx_t. I do not think that the ‘wsrep-ness’ of a transaction can change after the transaction has been started.
I removed all easily removable wsrep_on() calls from 10.1 and merged that up to 10.4. The code differed between each version quite a bit. For 10.5, there are only a few conflicts, and the code is very similar to 10.4.
Hi sergey!
Can you please provide the options which you used for perf. I attached perf to 2 node galera cluster running sysbench.
But I did not get any kind of call graph expansion for wsrep_on. This is because wsrep_on is called very less. Is there a way in perf to record call graph of less frequent functions ?
I used this for perf
sudo perf record -p 6520 -g