[MDEV-19896] --autoset-thread-cache-size doesn't work Created: 2019-06-28  Updated: 2019-11-20  Resolved: 2019-11-20

Status: Closed
Project: MariaDB Server
Component/s: Configuration, Documentation, Variables
Affects Version/s: 10.2, 10.3, 10.4
Fix Version/s: N/A

Type: Bug Priority: Major
Reporter: Geoff Montee (Inactive) Assignee: Ian Gilfillan
Resolution: Fixed Votes: 0
Labels: None

Issue Links:
Relates
relates to MDEV-19839 refactor --autoset Open
relates to MDEV-19895 Support "autoset" in SET GLOBAL for A... Open

 Description   

The documentation says that the thread_cache_size system variable supports auto-sizing in MariaDB 10.2 and later, and that auto-sizing is the default:

From MariaDB 10.2.0, the default is automatically set to the smaller of either 256, or the max_connections size.

https://mariadb.com/kb/en/library/server-system-variables/#thread_cache_size

However, this does not seem to be the case. This system variable does not support AUTO_SET, and the default is 256:

static Sys_var_ulong Sys_thread_cache_size(
 
       "thread_cache_size",
 
       "How many threads we should keep in a cache for reuse. These are freed after 5 minutes of idle time",
 
       GLOBAL_VAR(thread_cache_size), CMD_LINE(REQUIRED_ARG),
 
       VALID_RANGE(0, 16384), DEFAULT(256), BLOCK_SIZE(1));

https://github.com/MariaDB/server/blob/mariadb-10.4.6/sql/sys_vars.cc#L3655

The only time that this system variable appears to be auto-sized is if its configured value is greater than max_connections:

  /* Ensure that some variables are not set higher than needed */
 
  if (thread_cache_size > max_connections)
 
    SYSVAR_AUTOSIZE(thread_cache_size, max_connections);

https://github.com/MariaDB/server/blob/mariadb-10.4.6/sql/mysqld.cc#L9013

Is this a documentation bug, or is the behavior of thread_cache_size incorrect?

 Comments   
Comment by Sergei Golubchik [ 2019-10-30 ]

Looks like a documentation bug. It didn't do "smaller of either 256, or the max_connections size" even in 10.2.0

Generated at Thu Feb 08 08:55:11 UTC 2024 using Jira 8.20.16#820016-sha1:9d11dbea5f4be3d4cc21f03a88dd11d8c8687422.