我们在Digital Ocean上托管了一个MySQL（5.7.19-0ubuntu0.16.04.1-log）实例。具体而言，数据文件夹位于DO卷（也称为块存储）中。
几天前，我们注意到MySQL已经冻结了大约1个小时。在此期间，我们的网络服务器基本上也冻结了，所有请求都超时。
在调查我们的日志后，我们得到的唯一线索是：
2017-09-30T13:40:11.518265Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 3718180ms. The settings might not be optimal. (flushed=199 and evicted=0, during the time.)
据我所知this answer，这意味着它正在刷新199页，每页只有16KB，这意味着只需要刷新大约3MB的数据。这不应该需要一个小时才能完成。不幸的是，在停机期间我们没有出现，我们没有机会运行SHOW ENGINE INNODB STATUS
我们怀疑使用DigitalOcean的块存储与使用机器自己的SSD存在性能问题，但DO支持建议这不应该是一个问题。
此时，我们完全失去了可能导致问题的原因。我们甚至不确定page_cleaner是否是原因，或者它是否也是更深层次问题的受害者。
我想了解为什么会发生这种情况以及我们可以采取哪些措施来防止它发生。任何指针或调试此问题的方法都将非常感谢，谢谢！
==========更多信息==========
在我们继续调查的过程中，似乎发生了与此类似的问题，但我们几乎从未见过它，因为这些问题只需要几秒钟：
2017-09-29T07:34:43.346581Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 11628ms. The settings might not be optimal. (flushed=9 and evicted=0, during the time.)
2017-09-29T13:15:04.859060Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 7326ms. The settings might not be optimal. (flushed=111 and evicted=0, during the time.)
2017-09-29T22:45:14.299615Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 5621ms. The settings might not be optimal. (flushed=396 and evicted=0, during the time.)
2017-09-30T02:02:42.000685Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 4119ms. The settings might not be optimal. (flushed=10 and evicted=0, during the time.)
2017-09-30T02:02:54.424966Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 4704ms. The settings might not be optimal. (flushed=9 and evicted=0, during the time.)
2017-09-30T03:36:01.500662Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 7096ms. The settings might not be optimal. (flushed=9 and evicted=0, during the time.)
2017-09-30T03:36:07.747733Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 4100ms. The settings might not be optimal. (flushed=9 and evicted=0, during the time.)
我们已根据this的建议将innodb_lru_scan_depth调整为256，但我们没有看到任何改进。