Details
-
Task
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
-
None
Description
change temp-pool to be 0 by default and deprecate it
According to benchmarks made by Axel (and further analysis) , this code behind --temp-pool=1 in create_tmp_table() causes a heavy mutex contention:
if (use_temp_pool && !(test_flags & TEST_KEEP_TMP_TABLES)) |
|
|
temp_pool_slot = bitmap_lock_set_next(&temp_pool);
|
The --temp-pool option was implemented to address some bottleneck in Linux kernel, which is reported to be fixed nowadays.
In MySQL, --temp-pool was deprecated in 5.7 and removed in 8.0.
Let's do the following:
- Set --temp-pool=0 by default in MariaDB-10.5 (currently its default is 1)
- Mark it as deprecated in mysqld --help output
- Remove it in some later version, tentatively in 10.6.
In the meanwhile, we should try to find proves that this problem was really addressed in Linux.
Attachments
Issue Links
- is duplicated by
-
-
- Closed
-
- relates to
-
MDEV-25275 Remove temp-pool option and/or deprecate it properly
-
- Closed
-
-
-
- Closed
-
- links to
Activity
As far as I know temp-pool is still important. The problem it addressed was not related to linux kernel but with certain file system, like memory and proablly /dev/shm where old file names are left lingering for a long time. Reusing the file names gives both a speedup and avoid the file system being filled with deleted file names that causes both memory and performance issues.
I remember reading a bug report even this year that showed that this is still a problem.
I would really like to know what the following is referring to "address some bottleneck in Linux kernel, which is reported to be fixed nowadays"
We should NEVER delete any code or feature based on just 'hearsay' without any facts or complete understanding of the problem.
I do not see that for this case we have either.
I would also like to know more about the benchmark that was run that showed the problem.
We do not create temporary files so of then that this should be a bottleneck.
Note also that in newer MariaDB version, the function bitmap_set_next() is up to 8x faster than what we had in 10.5, which makes the mutex problem less severe.
We could also do a mutex free version with set-and-retry if the mutex would still be a problem.
For the reference, temp-pool was added in https://github.com/MariaDB/server/commit/882f16d0369
commit 882f16d0369
|
Author: Jeremy Cole <jeremy@mysql.com>
|
Date: Sat Jan 27 03:24:05 2001 -0600
|
|
|
Added --temp-pool option to mysqld. This will cause temporary files
|
created to use a small set of filenames, to try and avoid problems
|
in the Linux kernel.
|
Marked deprecated in MySQL in https://github.com/mysql/mysql-server/commit/bee8519a452b
commit bee8519a452
|
Author: Jon Olav Hauglid <jon.hauglid@oracle.com>
|
Date: Thu Jan 5 08:24:38 2017 +0100
|
|
|
WL#8396: Deprecate and remove temp-pool
|
|
This patch marks the temp-pool startup option as deprecated.
|
|
The patch is for MySQL 5.7.
|
Removed in https://github.com/mysql/mysql-server/commit/4b95f2f44445
commit 4b95f2f4444
|
Author: Jon Olav Hauglid <jon.hauglid@oracle.com>
|
Date: Fri Jan 13 15:49:57 2017 +0100
|
|
|
WL#8396: Deprecate and remove temp-pool
|
|
This patch removes the temp-pool startup option and related code.
|
This option only had effect for Linuxes and was a workaround for
|
an old Linux kernel bug.
|
|
This patch is for MySQL 8.0.
|
According to MDEV-34577 temp-pool still can help to avoid working-set memory growth in Docker
As per Sergei's comment, please never deprecate --temp-pool in MariaDB. Thank you.
https://github.com/MariaDB/server/commit/be974e56203c723b021a1a5e7719065298d7ceda