Details
-
Bug
-
Status: Closed (View Workflow)
-
Minor
-
Resolution: Fixed
-
10.5, 10.6
Description
The variable innodb_thread_concurrency was useful years ago when computing resources were limited, but nowadays setting this value to anything than unlimited (0) makes little sense and actually makes things worse ,because queries have to wait outside InnoDB.
We have seen many customers mistakenly setting this to a small value like 16 or 64 and then complaining the server was slow.
In the latest instantation of the above problem I've seen (just today), the available slots were all taken by long running transactions (left open) and the server was stalled as a result.
So, a dangerous config option and IMHO a good candidate for deprecation/removal.
Thanks
Rick
Attachments
Issue Links
- blocks
-
MDEV-23397 Remove deprecated InnoDB options in 10.6
-
- Closed
-
- relates to
-
MDEV-23382 Change DB_ROLL_PTR format to allow more than 128 concurrent START TRANSACTION
-
- Open
-
-
MDEV-25883 Galera Cluster hangs while "DELETE FROM mysql.wsrep_cluster"
-
- Closed
-
-
MDEV-11382 AliSQL: [Feature] Issue#9: PROVIDE ADAPTIVE ALGORITHM FOR INNODB CONCURRENCY TICKETS
-
- Closed
-
-
MDEV-14462 Confusing error message: ib_logfiles are too small for innodb_thread_concurrency=0
-
- Closed
-
-
MDEV-23369 False sharing in page_hash_latch::read_lock_wait()
-
- Closed
-
-
MDEV-24759 Server hangs when innodb_thread_concurrency is reached and temporary sequences exist
-
- Closed
-
-
MDEV-31220 MariaDB:performance seems to be limited when the value of parameter innodb_thread_concurrency is not zero
-
- Closed
-
Funny, I was thinking exactly the same yesterday, after fixing
MDEV-23369.With the
MDEV-23369fix in 10.5, we seem to scale rather well to an insane number of concurrent threads. I tested 1000 connections on a server where nproc reports 56. That would be at least 1033 threads on the server, and at least 1000 more threads for the client workload that was running on the same server.Yes, there is an inherent limit caused by there being only 128 rollback segments (the component in DB_ROLL_PTR is only 7 bits). The maximum write scalability ought to be reached with innodb_undo_tablespaces=128. But, we do not see a dramatic drop of the total throughput when we add more threads.
Hence, the ‘thread throttling’ at the high level by innodb_thread_concurrency or innodb_commit_concurrency does not seem to make much sense, and those parameters should probably be deprecated and ignored starting with the 10.6 release.