mysql优化---第7篇:参数 innodb_buffer_pool_instances设置

本文通过测试MySQL 5.6.7的InnoDB Buffer Pool性能,发现innodb_buffer_pool_instances参数对I/O负载有显著影响。特别是在高I/O负载时,该参数能够提升并发性能。

摘要:1 innodb_buffer_pool_instances可以开启多个内存缓冲池,把需要缓冲的数据hash到不同的缓冲池中,这样可以并行的内存读写。

2 innodb_buffer_pool_instances 参数显著的影响测试结果,特别是非常高的 I/O 负载时。

3 实验环境下, innodb_buffer_pool_instances=8 在很小的 buffer_pool 大小时有很大的不同,而使用大的 buffer_pool 时,innodb_buffer_pool_instances=1 的表现最棒。


1 定义

The number of regions that the InnoDB buffer pool is divided into. For systems with buffer pools in the multi-gigabyte range, dividing the buffer pool into separate instances can improve concurrency, by reducing contention as different threads read and write to cached pages. Each page that is stored in or read from the buffer pool is assigned to one of the buffer pool instances randomly, using a hashing function. Each buffer pool manages its own free lists, flush lists, LRUs, and all other data structures connected to a buffer pool, and is protected by its own buffer pool mutex.

This option takes effect only when you set the innodb_buffer_pool_size to a size of 1 gigabyte or more. The total size you specify is divided among all the buffer pools. For best efficiency, specify a combination ofinnodb_buffer_pool_instances and innodb_buffer_pool_size so that each buffer pool instance is at least 1 gigabyte.

  • 测试日期: Oct-2012
  • 测试目的: 测试 MySQL 5.6.7 的表现
  • 硬件换
    • 服务器: Dell PowerEdge R710
    • CPU: 2x Intel(R) Xeon(R) CPU E5-2660 0 @ 2.20GHz
    • 内存: 192GB(这个内存太猛了)
    • 存储: Very Fast PCIe Flash Card
    • 文件系统: ext4
  • 软件
    • 操作系统: CentOS 6.3
    • MySQL 版本: 5.6.7-RC
  • 测试规范
    • 测试工具: tpcc-mysql
    • 测试数据: 2500W (~250GB of data)
    • 测试时间: 总共测试 4000 秒,但只取最后的 2000 秒,避免因为冷启动的问题导致测试结果不准确
  • 不同的测试参数: 使用几组不同的 innodb_buffer_pool_size:13, 25, 50, 75, 100, 125GB ,innodb_buffer_pool_instances1 and 8, and innodb_log_file_size2x4GB and 2x8GB.

测试结果:

第一个结果使用的事 2x4GB 的 InnoDB 日志文件:

我们可看出当 innodb_buffer_pool_instances=8 在很小的 buffer_pool 大小时有很大的不同,而使用大的 buffer_pool 时,innodb_buffer_pool_instances=1 的表现最棒。

测试结果在大的 buffer_pool 时是很稳定的,原因是 InnoDB 使用异步 flush 模式,在新的 InnoDB flush 机制下以前的问题已经修复。不过 Dimitry 告诉我需要一个更大的 InnoDB 日志文件来获得更稳定的结果。

下面是 2x4GB vs 2x8GB innodb 日志文件大小的比较:

很显然,使用更大的日志文件,测试结果更稳定!

结论:

innodb_buffer_pool_instances 参数显著的影响测试结果,特别是非常高的 I/O 负载时。

在 MySQL 5.6 ,最终是可以获得非常稳定的吞吐,但自适应的 flush 机制仍需较大的日志文件。

MySQL 配置如下: 
01 [mysqld]
02 gdb
03  
04 innodb_file_per_table = true
05 innodb_data_file_path = ibdata1:100M:autoextend
06 innodb_flush_method = O_DIRECT
07 innodb_log_buffer_size = 256M
08  
09 innodb_flush_log_at_trx_commit = 1
10 innodb_buffer_pool_size = 125G
11 innodb_buffer_pool_instances=8
12  
13 innodb_log_file_size = 4G
14 innodb_log_files_in_group = 2
15 #####plugin options
16 innodb_read_io_threads = 16
17 innodb_write_io_threads = 16
18 innodb_io_capacity = 20000
19 innodb_io_capacity_max = 40000
20  
21  
22 #not innodb options (fixed)
23 port = 3306
24 back_log = 50
25 max_connections = 2000
26 max_prepared_stmt_count=500000
27 max_connect_errors = 10
28 table_open_cache = 2048
29 max_allowed_packet = 16M
30 binlog_cache_size = 16M
31 max_heap_table_size = 64M
32 sort_buffer_size = 4M
33 join_buffer_size = 4M
34 thread_cache_size = 1000
35 query_cache_size = 0
36 query_cache_type = 0
37 ft_min_word_len = 4
38 thread_stack = 192K
39 tmp_table_size = 64M
40  
41 server-id = 10
42 #*** MyISAM Specific options
43 key_buffer_size = 8M
44 read_buffer_size = 1M
45 read_rnd_buffer_size = 4M
46 bulk_insert_buffer_size = 8M
47 myisam_sort_buffer_size = 8M
48 myisam_max_sort_file_size = 10G
49 myisam_repair_threads = 1
50 myisam_recover
51 user=root
52 skip-grant-tables


转自:http://www.phpchina.com/archives/view-41968-1.html

<think> 嗯,用户这次聚焦在InnoDB的两个关键参数innodb_buffer_pool_instancesinnodb_buffer_pool_chunk_size的具体作用上。从引用内容看,用户已经做过功课,但需要更深入的技术解释。用户可能是在进行MySQL性能调优或解决高并发场景下的瓶颈问题。 用户引用的材料里提到三个参数的数学约束关系:$ buffer\_pool\_size = chunk\_size \times instances $。这个公式很关键,说明MySQL用几何约束确保内存分配合理性。需要强调这种设计背后的物理意义——避免内存碎片。 关于buffer_pool_instances,用户提供的引用[1]提到“缓冲池实例个数”,这涉及到并发优化的核心。实际应该解释锁争用问题:单一大缓冲池在64核服务器上,所有线程抢同一把锁会形成灾难性排队。分实例本质是分片,类似ConcurrentHashMap的分段锁思想。但要注意提醒用户实例数不是越多越好,引用[4]隐含了实例数与CPU核心数的关联。 chunk_size的参数作用更微妙。引用[2][3]强调它是动态调整的基准单位,但没说明设计初衷。其实chunk_size解决的是在线调整缓冲池大小的技术难题。早期MySQL重启才能改buffer_pool_size,现在通过chunk_size实现热调整。应该举例说明:假设原池子128GB,要扩到136GB,若chunk_size=128MB,实际会扩到128+128=256MB?不对重新算……应该是136/128≈1.0625向上取整得2个chunk,即实际扩到256MB?不对,按倍数关系应该是调整到innodb_buffer_pool_instances的整数倍?这里容易混淆,需要澄清:实际调整单位是chunk_size×instances,比如instances=8, chunk=128M,则最小调整单位是1GB。 用户可能隐含的问题是“如何设置最优值”。虽然他没直接问,但引用[4]提到物理内存50%-80%的区间暗示了这点。需要补充实践建议:比如chunk_size通常保持默认128MB,除非遇到“调整缓冲池时可用内存不足”的错误;instances建议设成CPU核心数,但最大不超过64。不过这些优化建议要放在相关问题里,避免偏离当前问题主体。 最后检查数学表达规范性:所有公式都用$...$包裹,关键约束$$ buffer\_pool\_size = chunk\_size \times instances $$独立成段。技术术语如LRU列表、刷新线程保持英文缩写,符合数据库领域惯例。 </think> 下面详细解释InnoDB缓冲池的两个关键参数作用及相互关系,遵循技术规范并结合引用内容: ### 一、核心参数作用 1. **`innodb_buffer_pool_instances`** - ✅ **并发优化**:将缓冲池拆分为多个独立区域(默认=8),每个实例管理自己的锁和数据结构 - ✅ **减少争用**:在高并发场景下降低线程间资源竞争(如避免所有线程争夺单一LRU列表锁)[^1][^3] - ✅ **内存分配**:实际内存分配公式: $$ \text{总内存} = \text{实例数} \times \text{块大小} \times N \quad (N为整数) $$ 2. **`innodb_buffer_pool_chunk_size`** - ✅ **动态调整单位**:缓冲池扩容/缩容的最小粒度(默认=128MB)[^2][^3] - ✅ **内存对齐**:保证内存块连续分配,避免碎片化 - ⚠️ **约束条件**:更改此值时,总缓冲池大小将自动调整为: $$ \text{新缓冲池大小} = \lceil \frac{\text{原大小}}{\text{新块大小} \times \text{实例数}} \rceil \times (\text{新块大小} \times \text{实例数}) $$ ### 二、参数间强制约束(数学关系) 根据引用[2][3][4]的硬性规则: ```math \text{innodb\_buffer\_pool\_size} \equiv 0 \quad (\text{mod } \text{innodb\_buffer\_pool\_chunk\_size} \times \text{innodb\_buffer\_pool\_instances}) ``` -设置值不符合倍数关系,MySQL将**自动向下取整**到最近的有效值 例如:设 `chunk_size=128MB`, `instances=4`,若指定 `pool_size=600MB` → 实际生效 512MB(因为 128×4=512 < 600 < 640) ### 三、配置实践建议 1. **实例数设置** - 原则:`实例数 ≈ min(CPU核心数, 64)` (避免过多实例增加管理开销) 2. **块大小调整** - 通常保持默认128MB,仅当需要>1TB缓冲池时可考虑增大 3. **总内存计算** - 最大值:`物理内存 × 75%`(需预留OS及其他进程内存)[^4] - 计算公式: $$ \text{pool\_size} = k \times \text{chunk\_size} \times \text{instances} \quad (k=1,2,3...) $$ ### 四、技术原理图解 ``` 缓冲池实例1 ├── Chunk 1 (128MB) ├── Chunk 2 (128MB) └── ... 缓冲池实例2 ├── Chunk 1 (128MB) ├── Chunk 2 (128MB) └── ... ``` ▸ 每个实例包含若干连续内存块 ▸ 所有实例的chunk大小必须一致 ▸ 数据页按哈希规则分配到不同实例 [^3]
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值