mcm*_*son 20 mysql innodb optimization logs configuration
在mysqld.log中看到这个注释:
[Note] InnoDB: page_cleaner: 1000ms intended loop took 15888ms. The settings might not be optimal. (flushed=200 and evicted=0, during the time.)
Run Code Online (Sandbox Code Playgroud)
这里似乎提到了这样的事情: MySQL 实例停滞“做 SYNC 索引”
我的问题是:当在日志中看到此注释时,应该采取什么措施(如果有)?
MySQL 和操作系统版本:
mysql-community-server- 5.7.9 -1.el7.x86_64
centos-release-7-1.1503.el7.centos.2.8.x86_64
运行SHOW VARIABLES LIKE 'innodb%'; 如建议所示:
innodb_page_cleaners | 1
Run Code Online (Sandbox Code Playgroud)
小智 13
MySQL 5.7.8 中的 innodb_page_cleaners 默认值从 1 更改为 4。如果页面清理线程的数量超过缓冲池实例的数量,则 innodb_page_cleaners 会自动设置为与 innodb_buffer_pool_instances 相同的值
使用以下命令检查 innodb_buffer_pool_instances:
mysql> SHOW GLOBAL VARIABLES LIKE 'innodb_buffer_pool_instances'
Run Code Online (Sandbox Code Playgroud)
您只能设置innodb_page_cleaners为innodb_buffer_pool_instances. 如果您愿意,innodb_page_cleaners=4那么您还需要innodb_buffer_pool_instances=4.
小智 7
我们在各种客户端都遇到了同样的问题,发现问题是由于将innodb_lru_scan_depth 的值从默认值 1024 设置为低至 128。虽然降低该值会减少处理事务所需的时间,尤其是在写绑定工作负载中我相信将值设置得太低会使缓冲池无法跟上清除其某些缓冲区和缓冲池脏页的速度。
在我们的例子中,通过将值从 128 增加到 256,我们看到了显着的改进,但通常正确的值取决于硬件和负载类型。诀窍是在提高 OLTP 性能和让 MySQL 保持缓冲池清洁之间找到正确的值,以免page_cleaner需要做很多工作,如上述消息所述(“InnoDB:page_cleaner:1000ms 预期循环花了 15888 毫秒" )。
该值可以在不重启 MySQL 的情况下动态更改,例如
SET GLOBAL innodb_lru_scan_depth=256;
Run Code Online (Sandbox Code Playgroud)
| 归档时间: |
|
| 查看次数: |
49856 次 |
| 最近记录: |