SQL Server中所说的“脏页”是什么意思
发布网友
发布时间：2022-04-08 01:01
共4个回答
懂视网
时间：2022-04-08 05:22
设置InnoDB后台进程最大的IO性能指标，例如从buffer pool中刷新刷新数据页，从insert buffer中合并数据等。
默认值是200，在繁忙的OLTP模式下，需要适当提高。
本文出自 “dba天空” 博客，请务必保留此出处http://9425473.blog.51cto.com/9415473/1670944
innodb_io_capacity
标签：linux
热心网友
时间：2022-04-08 02:30
一、Checkpoint（检查点）
Checkpoint会搜索整个data cache，将脏页回写到硬盘。
以下情况通常会触发checkpoint：
1、运行Checkpoint 命令。
2、使用alter database往数据库中添加了文件，或者从数据库中删除了文件。
3、备份数据库。在数据库备份之前，数据库引擎会自动执行检查点，以便在备份中包含对数据库数据页面的全部更改。
4、正常关闭SQL Server，并且不使用NOWAIT选项。
5、SQL Server预计的恢复时间超过了恢复间隔（recovery interval）。该值默认为0，即由SQL Server自动配置，一般为1分钟。一般情况下，按最低每分钟10MB日志进行设计。
以下特殊情况也会触发checkpoint：
1、当恢复模式为简单时，如果日志文件的空闲空间低于70%。例外的情况是：如果日志文件是由于一个事务长时间执行而且尚未结束（意味着没有空间可释放）导致空闲空间低于70%，则不会触发checkpoint。
2、当恢复模式为大容量日志时，对数据库做了一个大容量操作。
checkpoint对数据库的影响：
1、当数据库重启时，SQL Server将从checkpoint 完成的这个时间点开始恢复，即在此之后做redo（前滚）。这种机制加速了恢复的进度。
2、当恢复模式为简单时，checkpoint在把脏页回写到硬盘后，就去截断日志（将VLF的状态从2改为0）。
二、Lazywriter（惰性编辑器）
SQL
Server为每一个NUMA（非一致性内存访问）配备一个Lazywriter线程。Lazywriter被定期唤醒后，就去扫描与NUMA节点中的
data cache，检查自由列表（free list）。如果列表的大小低于某个阀值（这个阀值取决于data
cache的总大小）意味着内存压力，Lazywriter就去扫描data
cache，将其中一些页标记到自由列表，表示这是空闲内存；如果这些页中有脏页，就回写到硬盘。
当Lazywriter察觉到系统有内存压力时，它会增加或减少自由列表上的数据页，使操作系统的可用物理内存保持在4.8~5.2MB，以防止分页。
Lazywriter自SQL Server 2005被引入。它与checkpoint的主要区别：checkpoint不会去修改自由列表。
这是一个周期运行的线程，默认情况下，每隔一秒钟运行一次。
三、Worker Thread（工作线程）
SQL Server 启动时，同时启动30~40个工作线程，用于完成客户端连接提出的各种操作请求。当客户端连接增加时，SQL
Server会自动启动新的工作线程。当某个工作线程空闲15分钟，就会被关闭；当空闲内存不够时，某些工作线程也会被关闭（x86环境）。在x86环
境，每个工作线程至少占用0.5MB内存；在x64环境，每个工作线程至少占用2MB内存。
当worker线程察觉内存压力时，它会扫描data cache，把一段时间内未被访问的数据页添加到自由列表；如果这些页中有脏页，就回写到硬盘。
热心网友
时间：2022-04-08 03:48
发现每秒刷脏页的量和 SQL 被 kill 的量的曲线有点相近，看着刷脏页的量挺大的，但是每秒 delete 的 TPS 又不是很高，为啥这么低的 TPS 会让刷脏页频率抖动以及 SQL 执行变慢呢？曾经换过不同批次的机器，发现问题依旧，并没有改善，说明并不是机器本身的问题。继续浏览 buffer pool 相关的监控指标，像是发现新*一样的发现了一个异常指标脏页比例达到了快 90% ！！！太吓人了！！！为啥脏页比例会达到 90% 呢，无非就是刷脏页的速度跟不上产生的速度，要么就是 IO 能力不行，要么就是产生脏页的速度过快，要么就是内存池太小，导致 Buffer Pool 被脏页占满。那么这个脏页比例达到快 90% 会有什么问题呢？
innodb_max_dirty_pages_pct_lwm 表示的是当脏页比例达到该参数表示的低水位时候，刷脏线程就开始预刷脏来控制脏页比例，避免达到innodb_max_dirty_pages_pct 。刷脏页的最大 IO 能力是受 innodb_io_capacity 和 innodb_io_capacity_max 控制。生产上我们将 innodb_max_dirty_pages_pct_lwm 设置成了50当脏页比例大于 innodb_max_dirty_pages_pct 时候，InnoDB 会进行非常激烈的刷脏页操作，但是由于 DELETE 操作还是在进行，脏页产生的速度还是非常快，刷脏页的速度还是跟不上脏页产生的速度。为了避免脏页比例进一步扩大，更新将会被堵塞，从而导致 DELETE 执行变慢，直至被 KILL。发现问题之后，根据我们之前的假设，有三种解决方案：1. 调大 io_capacity ，但是由于主机是多实例部署，IO 占用已经比较高，PASS。2. 降低脏页产生速度，也就是调低 DELETE 速度，因为数据产生的速度很快，为了避免删除跟不上插入的速度，也被 PASS。3. 调大 Buffer Pool，可以容纳更多的脏页。说干就干，得益于 MySQL 5.7 的在线调整 Buffer Pool，立马将 Buffer Pool Size 扩了一倍，效果非常显著。
脏页比例立马下降，被 kill 的 SQL 也下降了。平均 SQL rt 下降很多。
总结
得益于 MySQL 的开源，很多错误都可以直接确认到对应的代码，大致定位到问题发生的地方，给问题排查带来了很多方便。同时对 MySQL buffer pool 的命中率以及脏页比例也要多多关注，对 SQL 的性能都有很大的影响。
热心网友
时间：2022-04-08 05:23
