Details
-
Task
-
Status: Closed (View Workflow)
-
Minor
-
Resolution: Fixed
-
None
Description
With MDEV-25340, MDEV-25341 and MDEV-24670 it would be good to ensure that the changes aren't frequently triggered and have a moderately substantial impact.
The current default innodb_buffer_pool_chunk_size of 128M results in 1024 segments for 128G RAM.
As the chunk size is designed around buffer pool resizing maybe 128 equating to just under 1% would be more appropriate.
So I'm thinking MAX(128M, buffer_pool_size / 128), then round down to a multiple of the next smallest large page size if large_pages are enabled, or a multiple of the OS page size otherwise.
Sound acceptable marko
Attachments
Issue Links
- causes
-
MDEV-27891 Delayed SIGSEGV in buf_pool_t::resize on InnoDB buffer pool resize after or during DROP TABLE
- Closed
- relates to
-
MDEV-24670 avoid OOM by linux kernel co-operative memory management
- Closed
-
MDEV-25340 Server startup with large innodb_buffer_pool_size takes a long time
- Open
-
MDEV-25341 innodb buffer pool soft decommit of memory
- Closed
-
MDEV-27461 Server hangs when the bufferpool is shrunk to 8M and innodb_page_size=64K
- Closed
-
MDEV-28803 ERROR 1206 (HY000): The total number of locks exceeds the lock table size
- Confirmed
-
MDEV-28805 SET GLOBAL innodb_buffer_pool_size=12*1024*1024 has different outcomes depending on version
- Closed