Details
-
Task
-
Status: Closed (View Workflow)
-
Critical
-
Resolution: Fixed
Description
This came up during the MDEV-15016 review.
I started to wonder whether multiple InnoDB buffer pools actually help with any workloads. Yes, it probably was a good idea to split the buffer pool mutex when Inaam Rana introduced multiple buffer pools in MySQL 5.5.5, but since then, there have been multiple fixes to reduce contention on the buffer pool mutex, such as Inaam's follow-up fix in MySQL 5.6.2 to use rw-locks instead of mutexes for the buf_pool->page_hash.
In MySQL 8.0.0, Shaohua Wang implemented one more thing that MariaDB should copy: MDEV-15053 Split buf_pool_t::mutex.
I think that we should seriously consider removing all code to support multiple buffer pools or page cleaners.
Should multiple buffer pools be needed in the future (for example, on NUMA machines), it should be designed better from the ground up. Currently the partitioning is arbitrary; buffer pool membership is basically determined by a hash of the page number.
The description of WL#6642: InnoDB: multiple page_cleaner threads seems to imply that it may have been a mistake to partition the buffer pool.
Note: partitioning or splitting mutexes often seems to be a good idea. But partitioning data structures or threads might not be.
axel, please test different workloads with innodb_buffer_pool_instances=1 and innodb_page_cleaners=1, and compare the performance to configurations that use multiple buffer pools (and page cleaners). If using a single buffer pool instance never seems to causes any regression, I think that we should simplify the code.
Attachments
Issue Links
- blocks
-
MDEV-21962 Allocate buf_pool statically
- Closed
- causes
-
MDEV-22027 Assertion oldest_lsn >= log_sys.last_checkpoint_lsn failed in log_checkpoint()
- Closed
-
MDEV-22114 Assertion `!is_owned()' failed. | handle_fatal_signal (sig=6) in MutexDebug
- Closed
-
MDEV-23399 10.5 performance regression with IO-bound tpcc
- Closed
-
MDEV-33966 sysbench performance regression with concurrent workloads
- Stalled
- relates to
-
MDEV-15053 Reduce buf_pool_t::mutex contention
- Closed
-
MDEV-21212 buf_page_get_gen -> buf_pool->stat.n_page_gets++ is a cpu waste (0.5-1%)
- Closed
-
MDEV-15016 multiple page cleaner threads use a lot of CPU on idle server
- Closed
-
MDEV-15685 large pages - out of memory handling results in SIGBUS sql/sql_show.cc:6822(get_schema_views_record
- Open
-
MDEV-16526 Overhaul the InnoDB page flushing
- Closed