Details
-
Bug
-
Status: In Review (View Workflow)
-
Critical
-
Resolution: Unresolved
-
11.8
-
Related to performance
-
Q1/2026 Server Maintenance, Q2/2026 Server Maintenance
Description
The regression test suite found a regression in test t_connect. This test is simple:
connect;
|
SELECT 1 FROM dual;
|
disconnect;
|
10.6.23-19 numbers:
thds tps min avg max 95th 25th median 75th
|
1 4121.35 0.189 0.242 2.834 0.256 0.235 0.239 0.245
|
2 8056.20 0.184 0.247 1.029 0.275 0.234 0.243 0.254
|
4 16338.05 0.177 0.244 1.025 0.290 0.222 0.236 0.257
|
8 27496.22 0.197 0.290 1.547 0.319 0.275 0.287 0.300
|
16 48598.15 0.197 0.328 2.693 0.381 0.303 0.323 0.344
|
32 66406.02 0.232 0.480 6.929 0.639 0.413 0.459 0.518
|
64 69616.80 0.243 0.917 20.697 1.417 0.712 0.844 1.012
|
128 68705.20 0.248 1.861 44.318 3.386 1.330 1.672 2.125
|
11.8.3-1 numbers:
thds tps min avg max 95th 25th median 75th
|
1 3909.42 0.190 0.255 2.648 0.276 0.246 0.253 0.259
|
2 7449.21 0.196 0.267 1.433 0.294 0.253 0.265 0.276
|
4 15387.43 0.187 0.259 1.201 0.308 0.234 0.252 0.275
|
8 25782.14 0.213 0.309 1.976 0.341 0.293 0.306 0.319
|
16 44968.59 0.221 0.354 3.236 0.415 0.327 0.348 0.372
|
32 58234.99 0.267 0.548 6.430 0.740 0.463 0.526 0.604
|
64 57565.59 0.274 1.110 17.304 1.762 0.823 1.037 1.300
|
128 54696.05 0.260 2.338 29.131 4.334 1.530 2.146 2.904
|
It should be investigated if this regression is avoidable or not. The regression does not depend on the new SSL capabilities of the server. Nor on the changed default character set. This has been tested already
With this patch
--- a/sql/sql_connect.cc
|
+++ b/sql/sql_connect.cc
|
@@ -1239,7 +1239,7 @@ static bool login_connection(THD *thd)
|
my_net_set_write_timeout(net, connect_timeout);
|
|
error= check_connection(thd);
|
- thd->session_tracker.sysvars.mark_all_as_changed(thd);
|
+ //thd->session_tracker.sysvars.mark_all_as_changed(thd);
|
thd->protocol->end_statement();
|
|
if (unlikely(error))
|
the performance of 11.8 is back to 11.4 level but not to 10.6.
Additionally with this patch
--- a/sql/protocol.cc
|
+++ b/sql/protocol.cc
|
@@ -269,12 +269,14 @@ Protocol::net_send_ok(THD *thd,
|
store.q_net_store_data((uchar*) safe_str(message), safe_strlen(message));
|
}
|
|
+ /*
|
if (unlikely(server_status & SERVER_SESSION_STATE_CHANGED))
|
{
|
store.set_charset(thd->variables.collation_database);
|
thd->session_tracker.store(thd, &store);
|
thd->server_status&= ~SERVER_SESSION_STATE_CHANGED;
|
}
|
+ */
|
|
DBUG_ASSERT(store.length() <= MAX_PACKET_LENGTH);
|
then 11.8 is even better than 10.5
Some details about the current code
A. Getting a value of SESSION sysvar seems to require two mutexes
One can see this in Session_sysvars_tracker::vars_list::store :
mysql_mutex_lock(&LOCK_global_system_variables);
|
mysql_mutex_lock(&LOCK_plugin);
|
if (!*node->test_load)
|
{
|
mysql_mutex_unlock(&LOCK_plugin);
|
mysql_mutex_unlock(&LOCK_global_system_variables);
|
continue;
|
}
|
...
|
mysql_mutex_lock(&LOCK_global_system_variables);
|
mysql_mutex_lock(&LOCK_plugin);
|
if (!*node->test_load)
|
{
|
mysql_mutex_unlock(&LOCK_plugin);
|
mysql_mutex_unlock(&LOCK_global_system_variables);
|
continue;
|
}
|
LOCK_plugin is needed because some variables come from plugins.
We use LOCK_plugin and check node->test_load to ensure that the responsible plugin is still loaded.
As for LOCK_global_system_variables:
The use of this mutex elsewhere suggests that one acquires it to get or set a GLOBAL variable value.
If one tries to track a global-only variable:
set session_track_system_variables='max_connections ... ';
|
...
|
one will reach this code
const uchar *sys_var::value_ptr(THD *thd, enum_var_type type, |
const LEX_CSTRING *base) const |
{
|
DBUG_ASSERT(base);
|
if (type == OPT_GLOBAL || scope() == GLOBAL) |
{
|
>> mysql_mutex_assert_owner(&LOCK_global_system_variables);
|
AutoRLock lock(guard);
|
which is called from get_one_variable|Session_sysvars_tracker::vars_list::store.
(although tracking of global variable won't work as setting a global value doesn't nmake a notification).
Takeaway from discussion with sanja: maybe it's possible to change this mechanism but we don't want to do that now.
B. If session sysvar is not changed, we don't acquire mutexes
See sys_var::update(). It has this call for updating session vars:
thd->session_tracker.sysvars.mark_as_changed(thd, var->var);
|
This notifies session_tracker.sysvars of the change. If no notification is made, the tracker won't check the sysvar value.
C. Sending initial sysvar values is achieved by marking all vars as having new values
See login_connection():
thd->session_tracker.sysvars.mark_all_as_changed(thd);
|
Attachments
Issue Links
- is caused by
-
MDEV-31609 Send initial values of system variables in first OK packet
-
- Closed
-
- relates to
-
-
- Closed
-
-
-
- Closed
-
- split to
-
-
- In Review
-
-
-
- In Review
-