MySQL 5.7.6 WL#7868 Innodb page flush优化

在最近release的5.7.6版本中又有了进一步的改进。

修改一、更精确的loop计算时间

page cleaner会每做srv_flushing_avg_loops次后，会去计算刷脏和redo lsn增长的速度。由于每次page cleaner的工作量是自适应的，一次flush操作的时间可能超过1秒，因此做n次loop的总时间可能超过n秒。

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

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

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

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

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

#根据当前脏页占比和lsn增长状态，计算利用io capacity的百分比（pct_total）

#计算目标lsn:

     target_lsn = oldest_lsn + lsn_avg_rate * buf_flush_lsn_scan_factor

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

#统计每个buffer pool 小于target_lsn的page数pages_for_lsn

初步估定每个bp instance 的n_pages_requested= pages_for_lsn /buf_flush_lsn_scan_factor

每个bp的pages_for_lsn被累加到sum_pages_for_lsn

#同时根据io capacity的百分比估算的总的page flush的量

sum_pages_for_lsn /= buf_flush_lsn_scan_factor;

n_pages = (pct_io(pct_total) + avg_page_rate + sum_pages_for_lsn) / 3;

n_pages若超过innodb_io_capacity_max，则设置为innodb_io_capacity_max

#轮询每个buffer pool instance：

如果当前有足够的redo 空间时：n_pages_requested  = n_pages / srv_buf_pool_instances

否则：n_pages_requested = n_pages_requested  * n_pages / sum_pages_for_lsn

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

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

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

修改三、用户线程在检查redo 空间时不参与刷脏

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

当用户线程参与到刷脏时，通常会认为这是个性能拐点，tps会出现急剧下降，大量线程陷入condtion wait。因此在5.7.6里，当用户线程需要推进lsn时，不再主动发起刷脏，而是轮询每个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文件是否容留了足够百分比的可用空间，但实际上并没有考虑即将写入到的redo log长度。如果我们操作一些极大的记录时，产生很长的redo log记录，可能导致检查点lsn被覆盖掉，造成不能做安全的crash recovery。

在新的逻辑里，在检测到当前写入的redo 可能造成覆盖检察点时，就会sleep等待page cleaner线程刷脏，并做redo log checkpoint。直到checkpoint的lsn推进到安全的位置。

除了上述几点外，还加入了更丰富的监控项