如何解决mysql警告：“ InnoDB：page_cleaner：1000毫秒的预期循环用了XXX毫秒设置可能不是最佳的”？

如何解决如何解决mysql警告：“ InnoDB：page_cleaner：1000毫秒的预期循环用了XXX毫秒设置可能不是最佳的”？？
InnoDB：page_cleaner：1000毫秒的预期循环耗时4013毫秒。设置可能不是最佳的。（在这段时间内刷新为1438，逐出为0）。

这个问题是典型的MysqL实例，其中您对数据库的更改率很高。通过运行5GB导入，您可以快速创建脏页。创建脏页时，页面清除器线程负责将脏页从内存复制到磁盘。

就您而言，我假设您并非一直都导入5GB。因此，这是非常高的数据负载率，而且是暂时的。您可能会忽略警告，因为InnoDB会逐渐赶上。

这是导致此警告的内部原因的详细说明。

每秒一次，页面清理程序扫描缓冲池中是否有脏页，以将其从缓冲池刷新到磁盘。您看到的警告表明它有很多脏页要刷新，并且需要花费4秒多的时间将一批脏页刷新到磁盘上，而这应该在1秒内完成。换句话说，它咬的东西超过了它的咀嚼能力。

您通过将它innodb_lru_scan_depth从1024 减少到256 进行了调整。这减少了页面清洁器线程在每秒一次的循环中搜索脏页到缓冲池的距离。您要求它咬一点。

请注意，如果您有许多缓冲池实例，它将导致刷新工作更多。它innodb_lru_scan_depth减少了每个缓冲池实例的工作量。因此，您可能在不减小扫描深度的情况下无意中通过增加了缓冲池的数量而导致了该瓶颈。

的文档innodb_lru_scan_depth说：“小于默认设置通常适用于大多数工作负载。” 听起来他们给此选项的默认值太高。

您可以使用innodb_io_capacity和innodb_io_capacity_max选项来限制后台冲洗使用的IOPS 。第一个选项是InnoDB将请求的I / O吞吐量的软限制。但是这个限制是灵活的。如果刷新落后于新的脏页创建速度，则InnoDB将动态增加刷新率，使其超过此限制。第二个选项对InnoDB可能增加刷新率的范围进行了更严格的限制。

如果刷新率能跟上创建新脏页的平均率，那么您会没事的。但是，如果您始终以比刷新它们快的速度创建脏页，则最终您的缓冲池将充满脏页，直到脏页超出innodb_max_dirty_page_pct缓冲池为止。此时，刷新率将自动增加，并可能再次导致page_cleaner发送警告。

另一个解决方案是将MysqL放在具有更快磁盘的服务器上。您需要一个I / O系统，该系统可以处理页面刷新所需的吞吐量。

如果您始终在平均流量下看到此警告，则可能是您尝试在此MysqL服务器上执行太多写查询。现在可能是横向扩展并将写入分成多个MysqL实例的时候了，每个实例都有自己的磁盘系统。

了解有关页面清洁器的更多信息：

在InnoDB中引入page_cleaner线程（归档副本）
MySQL-5.7改善了面向DML的工作负载
解决方法
我在服务器上运行了mysql import mysql dummyctrad
<dumpfile.sql，它花了太长时间才能完成。转储文件约为5G。该服务器是Centos 6，内存= 16G和8核处理器，mysql v 5.7
x64-

这些是正常消息/状态“正在等待表刷新”吗？ InnoDB: page_cleaner: 1000ms intended loop took 4013ms. The settings might not be optimal

mysql日志内容

2016-12-13T10:51:39.909382Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 4013ms. The settings might not be optimal. (flushed=1438 and evicted=0,during the time.)
2016-12-13T10:53:01.170388Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 4055ms. The settings might not be optimal. (flushed=1412 and evicted=0,during the time.)
2016-12-13T11:07:11.728812Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 4008ms. The settings might not be optimal. (flushed=1414 and evicted=0,during the time.)
2016-12-13T11:39:54.257618Z 3274915 [Note] Aborted connection 3274915 to db: 'dummyctrad' user: 'root' host: 'localhost' (Got an error writing communication packets)
流程清单：

mysql> show processlist \G;
1. row **

 Id: 3273081

User: root
Host: localhost

 db: dummyctrad

Command: Field List
Time: 7580
State: Waiting for table flush
Info:
2. row **

 Id: 3274915

User: root
Host: localhost

 db: dummyctrad

Command: Query
Time: 2
State: update
Info: INSERT INTO radacct VALUES (351318325,'kxid ge:7186','abcxyz5976c','user100
3. row **

 Id: 3291591

User: root
Host: localhost

 db: NULL

Command: Query
Time: 0
State: starting
Info: show processlist
4. row **

 Id: 3291657

User: remoteuser
Host: portal.example.com:32800

 db: ctradius

Command: Sleep
Time: 2
State:
Info: NULL
4 rows in set (0.00 sec)
更新1

mysqlforum，innodb_lru_scan_depth

将innodb_lru_scan_depth值更改为256可改善插入查询的执行时间+日志中无警告消息，默认值为innodb_lru_scan_depth =
1024;

SET GLOBAL innodb_lru_scan_depth=256;

声明：地推任务网所有作品（图片、文字）均由用户自行上传分享，仅供网友学习交流。