Details
-
Bug
-
Status: Closed (View Workflow)
-
Major
-
Resolution: Fixed
-
10.6, 10.11, 11.3(EOL), 11.4
Description
Running sysbench with Intel's VTune, I've noticed there is large-ish contention in ha_innobase::info_low(), if flag contains HA_STATUS_VARIABLE.
It is a cached workload, database is started with large enough buffer pool 10G.
sysbench is run for 1 table x 1000000 rows, oltp_point_select, 400 users.
.\sysbench.exe oltp_point_select --table-size=10000000 --mysql-user=root --report-interval=1 --time=30 --threads=400 --point-selects=0 --mysql-db=sbtest --mysql-ssl=off --histogram=1 run
I'm attaching the flamegraph screenshots (sorry for this, but it does not seem to be possible to export that in svg from VTune)
The code in question is this
ib_table->stats_mutex_lock();
|
|
ut_a(ib_table->stat_initialized);
|
|
n_rows = ib_table->stat_n_rows;
|
|
stat_clustered_index_size
|
= ib_table->stat_clustered_index_size;
|
|
stat_sum_of_other_index_sizes
|
= ib_table->stat_sum_of_other_index_sizes;
|
|
ib_table->stats_mutex_unlock();
|
the callstack is
ntdll.dll ! ZwWaitForAlertByThreadId
|
ntdll.dll ! RtlpWaitOnAddressWithTimeout + 0x80
|
ntdll.dll ! RtlpWaitOnAddress + 0xd7
|
ntdll.dll ! RtlWaitOnAddress + 0x12
|
KERNELBASE.dll ! WaitOnAddress + 0x32
|
server.dll ! srw_mutex_impl<1>::wait + 0x18 - srw_lock.cc:202
|
server.dll ! srw_mutex_impl<1>::wait_and_lock + 0x60 - srw_lock.cc:324
|
server.dll ! srw_mutex_impl<1>::wr_lock + 0x10 - srw_lock.h:134
|
server.dll ! dict_table_t::lock_mutex_lock + 0x7 - dict0mem.h:2011
|
server.dll ! dict_table_t::stats_mutex_lock - dict0mem.h:2039
|
server.dll ! ha_innobase::info_low + 0x202 - ha_innodb.cc:14787
|
server.dll ! make_join_statistics + 0x20c - sql_select.cc:5499
|
server.dll ! JOIN::optimize_inner + 0x1cff - sql_select.cc:2625
|
server.dll ! JOIN::optimize + 0x8b - sql_select.cc:1944
|
server.dll ! mysql_select + 0x2e1 - sql_select.cc:5235
|
server.dll ! handle_select + 0x1f9 - sql_select.cc:628
|
server.dll ! execute_sqlcom_select + 0x2e5 - sql_parse.cc:6012
|
server.dll ! mysql_execute_command + 0xac6 - sql_parse.cc:3911
|
server.dll ! Prepared_statement::execute + 0x2b3 - sql_prepare.cc:5027
|
...
|
It seems like mutual exclusion is an overkill here, as no data is being changed. Perhaps a slim rwlock would be better?
Attachments
Issue Links
- causes
-
MDEV-35046 SIGSEGV in list_delete in optimized builds when using pseudo_slave_mode
- Closed
- relates to
-
MDEV-25029 Reduce dict_sys mutex contention for read-only workload
- Closed
-
MDEV-33966 sysbench performance regression with concurrent workloads
- Stalled