2016-12-14 1522 views
9

我在服务器上运行了一个mysql导入mysql dummyctrad < dumpfile.sql,并且它需要很长时间才能完成。转储文件大约5G。服务器的centos 6内存= 16G和8core处理器,MySQL的v 5.7 64如何解决mysql警告:“InnoDB:page_cleaner:1000ms预期的循环花了XXX毫秒,这些设置可能不是最优的”?

这些是正常的消息/状态 “等待表冲洗” 和消息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) 

PROCESSLIST \

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

mysqlforuminnodb_lru_scan_depth

改变innodb_lru_scan_depth值256具有改进的插入件的查询执行时间+在日志中没有警告消息,默认是innodb_lru_scan_depth = 1024;

SET GLOBAL innodb_lru_scan_depth=256;

+1

有什么实际问题?花太长的时间并不是我认为成为一次性过程的问题!你能更具体一些吗,如果你看到什么错误?你有没有可能表明发生了什么的日志?对不起,只是没有足够的信息给任何人提供帮助 – jamesc

+0

什么是实际*问题*?这更像是状态报告而不是问题。 – spencer7593

回答

27

InnoDB的:page_cleaner:1000ms的预期循环了4013ms。这些设置可能不是最佳的。 (冲洗= 1438和逐出= 0时,在该时间。)

问题是典型的,你必须更改数据库的高速率的MySQL实例的。通过运行5GB导入,您可以快速创建脏页面。当脏页面被创建时,页面清理器线程负责将脏页面从内存复制到磁盘。

在你的情况,我假设你不会一直做5GB的进口。所以这是一个非常高的数据加载速度,而且是暂时的。你可能会忽视这些警告,因为InnoDB会逐渐赶上。


下面是导致此警告的内部结构的详细说明。

页面清理程序每秒扫描缓冲池中的脏页以从缓冲池刷新到磁盘。您看到的警告显示它有大量脏页面需要刷新,并且需要4秒钟时间才能将其中的一批刷新到磁盘,并在1秒内完成该工作。换句话说,它咬的比咀嚼更多。

您通过将其从innodb_lru_scan_depth从1024减少到256来调整此值。这减少了页面清理器线程在其每秒一次循环中搜索脏页面的时间。你要求它采取较小的叮咬。

请注意,如果您有许多缓冲池实例,它会导致刷新做更多的工作。它咬下每个缓冲池实例的工作量innodb_lru_scan_depth。因此,您可能无意中通过增加缓冲池的数量而不减少扫描深度来造成此瓶颈。

innodb_lru_scan_depth的文档中提到“小于默认值的设置通常适用于大多数工作负载。”这听起来像是他们给这个选项的默认值太高了。

您可以通过选项innodb_io_capacityinnodb_io_capacity_max来限制背景刷新使用的IOPS。第一个选项是InnoDB将要求的I/O吞吐量的软限制。但这个限制是灵活的;如果刷新速度落后于创建新脏页面的速度,InnoDB会动态增加超出此限制的刷新速率。第二个选项对InnoDB可能提高冲洗速度的程度进行了更严格的限制。

如果冲洗速度能够跟上创建新脏页面的平均速度,那么你会没事的。但是,如果您一直创建的脏页比刷新更快,最终您的缓冲池将填满脏页,直到脏页超过缓冲池的innodb_max_dirty_page_pct。此时,冲洗速率会自动增加,并可能再次导致page_cleaner发送警告。

另一种解决方案是将MySQL放在具有更快磁盘的服务器上。您需要一个I/O系统来处理页面冲洗所需的吞吐量。

如果你在平均流量下一直看到这个警告,你可能会试图在这个MySQL服务器上做太多的写查询。它可能是时候扩展,并将写入分割成多个MySQL实例,每个实例都有自己的磁盘系统。

了解更多关于在网页吸尘器:https://blogs.oracle.com/mysqlinnodb/entry/introducing_page_cleaner_thread_in

+0

将innodb_lru_scan_depth设置为256并未解决问题 –

+0

@KarimSamir,值256没有什么特别之处。这是OP使用的示例。 –

+0

是的,我知道,你能否建议我可以做的其他事情来解决这个问题? –

相关问题