Details
-
Bug
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
11.3
-
None
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?
