[MDEV-7962] wsrep_on() takes 0.14% in OLTP RO Created: 2015-04-09  Updated: 2020-05-04  Resolved: 2020-04-27

Status: Closed
Project: MariaDB Server
Component/s: Galera
Affects Version/s: 10.1.6, 10.2.0, 10.3.0, 10.4.0, 10.5.0
Fix Version/s: 10.1.45, 10.2.32, 10.3.23, 10.4.13, 10.5.3

Type: Bug Priority: Major
Reporter: Sergey Vojtovich Assignee: Marko Mäkelä
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Problem/Incident
causes MDEV-22452 Missing call to wsrep_commit_ordered ... Closed
Relates
relates to MDEV-22203 WSREP_ON is unnecessarily expensive t... Closed
Epic Link: Performance: micro optimizations

 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.

 Comments   
Comment by Sachin Setiya (Inactive) [ 2016-12-28 ]

Hi sergey!

Can you please provide the options which you used for perf. I attached perf to 2 node galera cluster running sysbench.

0.05%     0.05%  mysqld   mysqld               [.] wsrep_on

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

Comment by Marko Mäkelä [ 2020-04-17 ]

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-16799 renamed to WSREP_ON_NEW, and related to MDEV-16405 (Galera 4) in 10.4.2 the more efficient macro WSREP_ON was replaced altogether.

Comment by Marko Mäkelä [ 2020-04-17 ]

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?

Comment by Marko Mäkelä [ 2020-04-24 ]

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?

Comment by Marko Mäkelä [ 2020-04-27 ]

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.

Comment by Marko Mäkelä [ 2020-04-27 ]

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.

Generated at Thu Feb 08 07:23:37 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.