修改一、更精确的loop时间

Page cleaner每做srv_flushing_avg_loops次flush后，会去计算刷脏和Redo LSN增长的速度。由于每次Page cleaner的工作量是自适应的，一次flush操作的时间可能超过1秒。

在新版本中，统一采用当前时间和上次更新速率的时间差来确认是否需要重新计算速率。因此参数innodb_flushing_avg_loops的行为实际上等同于每这么多秒后重计算速率。

修改二、根据buffer pool实例的脏页分布来决定刷脏

从5.7版本开始支持配置多个page cleaner线程以实现并行刷脏。在5.7.6之前的版本，Page cleaner协调线程根据当前的负载情况，会计算出预计需要flush的总page数和目标LSN，然后在多个bp instance间做个均分。

但是考虑一种场景：如果bp实例间的负载不平衡，某个实例在目标LSN之前的脏页很多，而有些实例很少，那么本应该多做刷脏动作的bp就可能产生堆积。 我们之前在 有过类似的讨论，感兴趣的可以看看。

回到正题上来，在5.7.6版本中，计算目标page数的方法大概如下：

其中oldest_lsn表示当前buffer pool中最老page的LSN，lsn_avg_rate表示每秒LSN推进的平均速率，buf_flush_lsn_scan_factor目前是hardcode的，值为3。

初步估定每个bp instance 的n_pages_requested= pages_for_lsn /buf_flush_lsn_scan_factor。每个bp的pages_for_lsn被累加到sum_pages_for_lsn

n_pages若超过innodb_io_capacity_max，则设置为innodb_io_capacity_max

也就是说，在Redo 空间足够时，依然采用均衡的刷脏逻辑。

在早期版本中，会根据两个条件来判断每个bp刷脏的进度：目标LSN及page数。而到了5.7.6版本里，大多数情况下只根据更加准确的请求刷page数来进行判定 （系统空闲时进行100% io capactiy的page flush、崩溃恢复时、以及实例shutdown时的刷脏除外）

虽然计算公式比较清晰，但有些factor的定值依然让人很困惑，也许是官方测试的比较理想的配置。不过最好还是设置成可配置的，由有经验的用户根据自己具体的负载情况来进行定制。

在之前版本中，当未做checkpoint的日志量过多时，用户线程会进行batch flush操作，将每个buffer pool instance的LSN推进到某个指定值。如果某个bp instance已经有别的线程在flush，则跳过尝试下一个instance，同时认为这次的flush操作是失败的，会返回重试。

当用户线程参与到刷脏时，通常会认为这是个性能拐点，TPS会出现急剧下降，大量线程陷入condtion wait 和并发flush。因此在5.7.6里，当用户线程需要推进LSN时，不再主动发起刷脏，这些工作会留给page cleaner线程来作。 用户线程只去轮询每个bp instance，直到所有的bp instance 的LSN超过其目标LSN，每次轮询默认sleep重试时间为10000微妙

事实上, Percona Server早在5.6版本里已经使用相同的策略了。

修改四、为page cleaner线程设置更高的优先级

在Linux平台下，对于page cleaner的协调线程和worker线程，其CPU优先级被设置为-20，即最高优先级，通过函数set_priority设置。目前还不支持参数配置。

修改五、防止checkpoint LSN被覆盖

在之前的版本中，尽管每次在写Redo时都会去检查日志文件是否容留了足够百分比的可用空间，但实际上并没有考虑即将写入的Redo log长度。如果我们操作一些极大的记录并产生很长的Redo log记录，这可能导致检查点LSN被覆盖掉，如果这时候crash就会无法安全的做崩溃恢复。

参考： worklog：wl#7868，及