页面预期寿命和磁盘 IO 吞吐量之间是否存在确定性关系？
var*_*ble -2 sql-server page-life-expectancy sql-server-2019
从页面预期寿命开始，它应该远高于 300。这告诉您页面在缓冲池中停留的时间，值 300 相当于 5 分钟。如果您有 120GB 的缓冲池，并且其运行时间超过 5 分钟，则相当于系统持续的磁盘 I/O 速度为 409.6 MB/秒，这是必须维持的大量磁盘活动。
链接： https: //deltabravo.ai/delta-bravo-performance-counters-sql-server-target-vs-total-memory/
使用的公式好像是->磁盘IO吞吐量=缓冲池内存*1024/PLE
这是确定磁盘 IO 吞吐量的正确方法吗？
sqL*_*dLe 10
\xe2\x80\x99 表明数据库数据文件字节/秒吞吐量（可以在一段时间内直接测量）和 SQL Server 页面预期寿命（这是一个估计值）之间存在如此直接的关系，这完全不符合实际情况。根据 Microsoft 从未公开披露的多因素模型随着时间的推移进行更新:-)
\n我将在这里比您最初想到的更详细地讨论，但我认为人们重要的是要考虑诸如页面预期寿命或缓冲区缓存命中率之类的综合衡量标准中可能涉及哪些因素，等等，以便更全面地了解工作负载活动和资源如何交互 - 特别是在自适应或预测性配置资源时。
\n关于该模型已知的一件事：在具有多个 (v)NUMA 节点的系统上，每个节点都按预期配置了 (v)RAM（并且没有任何启动跟踪标志的干预来告诉 SQLOS 执行不同的操作），SQLOS 将创建一个 SQLOS 内存节点对于每个 (v)NUMA 节点（除了 ID 为 64 的非常小的始终存在的 SQLOS 内存节点，其创建只是为了容纳 DAC）。
\n当有多个 SQLOS 内存节点，每个 SQLOS 内存节点都有不同的 \xe2\x80\x9chome\xe2\x80\x9d (v)NUMA 节点时，每个这样的 SQLOS 内存节点将基于资源监视器线程、惰性写入器及其自己的线程进行管理记忆目标。通过协调每个 SQLOS 内存节点的内存管理，SQL Server 根据系统范围内存目标来管理系统范围 SQLOS 共享内存。作为该一揽子交易的一部分，每个 SQLOS 内存节点都有自己的估计 PLE 随着时间的推移而更新，根据用于估计仅具有 SQLOS 内存节点0的系统上的一个用户可访问 SQLOS 内存节点的 PLE 的相同未公开模型和64。
\n但关于具有多个 (v)NUMA 节点和多个 SQLOS 节点的系统上的 PLE，我们知道一件事。系统范围的 PLE 计算为构成 SQLOS 内存节点的各个 PLE 的调和平均值。
\nPaul Randal 几年前在这篇博文中讨论过这个细节。
\n页面预期寿命\xe2\x80\x99不是你想象的那样——2011年10月19日
\n几年后，Paul Randal 详细说明了系统范围的 PLE 是调和平均值而不是算术平均值后，我研究了一个示例。
\nNUMA 服务器上 SQLOS 缓冲区节点 PLE 的调和平均值 - 2016 年 10 月 25 日
\n好的。因此，有关具有多个 (v)NUMA 节点和 SQLOS 内存节点的系统的调和平均值的详细信息实际上是我们所知道的唯一详细信息。但是我们可以思考计算单个 SQLOS 节点的 PLE 时可能包含哪些因素，这对于思考数据库行为非常有启发性。
\n作为一个思想实验，让我们想象一个 DBAsCHOICE 数据库系统。数据库文件包含 10 TB 数据 - 1000 个堆，每个堆大小为 10 GB。数据库中没有任何类型的 B 树索引或用户索引。它位于具有 150 GB RAM 的服务器上，数据库缓存的大小始终保持在 100 GB。数据库缓存通过严格的 LRUQ 进行管理。假想的工作负载是只读的：\nSELECT * FROM x WHERE ID = -1\n对于 1000 个不同的堆名称中的每一个。这些堆中没有一个具有 ID = -1 的行。一千个表中的每一个都执行了全扫描，然后直到所有 999 个其他堆都开始了全扫描（几乎所有堆都在该表的下一次全扫描发生时完成）才开始另一个全扫描。由于我正在弥补，所以工作量是完美的。无写入活动。没有排序或哈希。没有临时表。不会掉落桌子。所有的阅读，所有的时间，并寻找那些查询永远找不到的东西。
\n由于数据库缓存的大小是恒定的，并且唯一的活动是读取活动，因此在任何两个时间点之间，从存储读取到数据库缓存中的数据库页数等于从缓存中逐出的数据库页数。要对 10GB 堆进行全扫描，必须逐出 10GB 的最旧数据库页面。
\n数据库缓存大小是固定且已知的。假想的工作负载保证缓存将不断地搅动。每个数据库页面只是单调地从缓存跟踪的 MRU 端行进到 LRU 端，然后从缓存中逐出。在这种情况下，数据库页在数据库缓存中保留的时间量与从数据库页读取字节/秒的吞吐量之间存在精确的关系。
\n这只是一个童话故事。SQL Server 不是这样工作的。:-)
\n首先，数据库缓存并不是固定大小的。考虑到 SQLOS 目标服务器内存，数据库缓存可根据被盗和释放内存进行自适应管理。下图显示了内存如何适应使用以及随着时间的推移预测的使用情况。数据库缓存大小的显着减少 - 假设数据库非不受欢迎页面读取的速率接近恒定（并且不受欢迎的读取或写入活动都没有 - Haven\xe2\x80\x99t 甚至还没有到达那里 LoL） - 将导致很多数据库页面的\xe2\x80\x9ccache 保持时间\xe2\x80\x9d 更短，PLE 也更低。
\n
嗯。关于不受欢迎的页面的\xe2\x80\x99s 内容是什么？好吧，让 \xe2\x80\x99s 谈谈 \xe2\x80\x9cregular\xe2\x80\x9d 页面读取之外的其他因素，这些因素会影响数据库缓存行为和管理，我们\xe2\x80\x99将不受欢迎（并且超出）。
\n描述队列规则详细说明了队列的管理方式 - 进入和溢出、优先级、生命周期、驱逐。SQL Server 数据库缓存队列规则比简单的最近最少使用队列更强大，其中要逐出的项目始终是最近接触时间最长的项目。最重要的规则是 LRU2 - LRUk 算法一般策略的实现，该算法主要依赖于数据库页面的单个最新引用，以及 k 个最新引用。
\n我认为 bpool LRU2 算法非常灵活；它承认某些数据库页面在缓存中比最近触及的时间戳本身更有价值。一般来说，当需要从缓存中逐出页面以维持或达到目标大小时（与删除数据库时通过启发式逐出相反），最旧的倒数第二个触摸是我们期望发生逐出的位置。
\n呵呵。那\xe2\x80\x99s 肯定开始偏离基于读取率的简单预测。如果有\xe2\x80\x99s来自热表的一些GB数据库页面，这些页面总是从逐出中保存下来，因为这些页面被频繁触及 - 那\xe2\x80\x99s将影响其他页面的缓存保留时间，并且我期望这能够反映在 PLE 中（取决于 PLE 算法的具体情况）。
\n好吧，让\xe2\x80\x99s 更接近不受欢迎。如果会计部门的 Gil 始终在最大服务器内存设置为 100 GB 的实例中运行 2TB 堆的全扫描，该怎么办？（Gil\xe2\x80\x99s 全扫描查询也很神奇，它总是会两次触及该堆的每个页面 - 就好像它是故意设计来对 LRU2 缓存管理造成严重破坏一样。） Gil 会继续搅动其他所有内容吗？数据库缓存和 2TB 的堆页？
\n当这种情况发生时 - 当缓存被大量低价值的东西溢出时 - 它\xe2\x80\x99s称为缓存污染。数据库页面不利于调整 bpool 队列门徒，以减轻缓存污染的风险。它\xe2\x80\x99是对相关页面的触摸时间戳的操作，以便很快地将它们从缓存中逐出。Gil\xe2\x80\x99s 对该 2 TB 堆进行全面扫描\xe2\x80\x99 不太可能污染该实例的数据库缓存（最大服务器内存 = 100 GB），因为这些页面将很快被不受欢迎并从数据库缓存中逐出 -允许其他内容在缓存中保留更长时间。对超过数据库缓存大小阈值百分比的 HoBT 进行全扫描就是一个示例，其中不利操作系统并导致数据库页面的缓存保留时间与单独基于字节/秒读取吞吐量和数据库缓存大小的预测不同。我\xe2\x80\x99d 预计 PLE 会因此而改变。
\n上面我提到，启发式的 bpool 逐出会对数据库缓存大小产生重大影响，因此预计会对 PLE 产生巨大影响，无法通过单独读取来预测\xe2\x80\x99。删除数据库就是一个示例，其中包括删除快照数据库。默认情况下，在常规用户数据库中运行 dbcc checkdb 将创建一个内部快照数据库并对快照数据库执行读取。在 bpool 中，这些页面与快照数据库关联，而不是与基础数据库关联。当 checkdb 完成时，内部快照数据库将被删除。与突然删除的快照数据库关联的每个数据库页面都会从缓存中逐出。结果数据库缓存会更小；在恒定读取速率下，缓存保持时间会较短。我\xe2\x80\x99d 期望 PLE 较低，在某种程度上可以\xe2\x80\x99t 与磁盘字节/秒吞吐量挂钩。
\n现在让\xe2\x80\x99s 谈谈数据库页写入、bpool 中的脏页以及对 PLE 的潜在影响。bpool 中的脏数据库页可能首先从磁盘读取以进行更改 - 如果它之前已被分配并具有内容。
\n但想象一下，在最大服务器内存 = 100 GB 的同一个 SQL Server 实例中，根本没有非系统活动。没有什么会强制从 bpool 中驱逐。所以 PLE 会不断攀升，直到 \xe2\x80\x99 相当高。添加一个会话，仅将包含 5000 个重复破折号字符的行填充到 tempdb 中新创建的未压缩临时表中。桌子是新的。分配将是全新的——SQL Server 知道这一点。无需读取未分配的空数据库页面（或 8 个页面的 64 kb 范围）即可在 bpool 中创建页面 - 然后可以稍后写入它们，对吗？\n但是页面现在已新进入 bpool。\xe2\x80\x99s 会降低 PLE - 没有任何读取（好吧，也许从系统对象读取一些元数据） - 并且读取字节/秒不会 \xe2\x80\x99t 有话要说。
\n我们是否会捕获 tempdb 数据文件写入中的 bpool 活动，这可能与 PLE 值和更改有关？或许。但只是也许。与用户数据库相比，tempdb 现在具有延迟写入行为。如果该会话在延迟写入开始之前删除或截断临时表？瞧！完美犯罪！PLE 更改不会在磁盘读取字节/秒或写入字节/秒中留下任何痕迹。
\n好吧 - 这里还要提到三件事，作为数据库数据文件字节/秒流量和 PLE 之间关系的混淆因素。绕过 bpool 的字节/秒数据文件流量怎么样？I\xe2\x80\x99ll 给出一个读取示例和一个写入示例 - I\xe2\x80\x99m 当然还有其他示例。对于读取 - 备份怎么样？将会获得大量的数据文件读取流量。Won\xe2\x80\x99t 对 PLE 有任何直接影响，因为读取流量进入与数据库缓存完全分离的备份缓冲区。
\n现在是一个写入示例：假设实例中未启用即时文件初始化，并且数据库文件增长了 50 GB。将有很多字节写入该数据库文件。但是将 50 个 1 GB 堆读入缓存对 PLE 有何影响？或者创建并填充 50 个新的 1 GB 堆并调用手动检查点？没有。
\n接下来让\xe2\x80\x99s考虑计算PLE的算法或模型。我不认为\xe2\x80\x99像最近N分钟的线性外推一样简单。我感觉该模型具有预测性，包含了预计的加速或减速的未来活动。
\n例如，3 分钟前活动请求计数为 c0，bpool 流入率为 y0，bpool 驱逐率为 z0，bpool 大小为 x0。1 分钟前 c1 活动请求、bpool 流入率 y1、bpool 驱逐率 z1 和 bpool 大小 x1。c1、y1 和 z1 均大于其各自之前的对应项 c0、y0 和 z0。bpool 大小 x1 小于先前对应的 x0。活跃请求的数量有所增加。进出交通量均有所增长。数据库缓存大小缩小。我打赌 PLE 模型将预测一些持续的加速 - 预计在不久的将来会有更多的并发活动请求、更高的进出率以及由于被盗内存带来的压力增加而导致的数据库缓存大小甚至更小。我们\xe2\x80\x99d只能确定微软是否泄露了有关PLE模型的更多信息。但我敢打赌有\xe2\x80\x99s类似的东西。
\n不过，预测可能而且经常是错误的。在某个时刻，该实例将达到并发请求的峰值数量、峰值速率、峰值输出速率和最小数据库缓存大小。高峰过后，活动将趋于稳定或下降。但如果 SQL Server 预测会持续加速，那么 PLE 将更多地反映不真实的预测而不是现实。当减速的预测遇到活动的意外加速时，也会发生同样的事情。
\n好吧，最后一张。感谢您的坚持:-)。错误可能会使 PLE 无法根据数据库数据文件的字节/秒流量进行解释。在以下链接中，我探讨了具有多个 (v)NUMA 节点的系统上早期 SQL Server 2016 中存在的错误（现已修复）。SQLOS 内存的很大一部分可能会被重复计算和重复记账。当此错误发生时，同一部分内存将显示为节点 A 的数据库缓存和节点 B 的被盗内存。这种错误表示导致了尝试理解实例中的活动和行为的各种困难。并导致 PLE 与正常活动的代表距离稍远。
\nSQL Server 2016 内存核算第二部分：另一个可疑示例
\n对 PLE 和数据库文件的字节/秒流量之间的相关性的考虑肯定不是详尽无遗的，即使亲爱的读者早已精疲力尽:-)但我想确保人们真正考虑什么\xe2\x80\x99s以描述数据库资源和活动的各种指标进行测量和表示。我个人认为 PLE 和其他计算指标（例如缓存命中率）是需要解释的东西，而不是确实解释的东西。
\n我\xe2\x80\x99d 宁愿以 PLE 中的因素作为起点。我几乎总是随着时间的推移查看 SQLOS 内存以了解实例的行为。数据库缓存、可用内存和被盗内存的堆叠图非常有帮助。数据库页面每秒读取和写入等。
\n尽管 bpool 代理职员（如列存储对象池代理职员）具有用于逐出/秒（压力和定期 iirc）的 perfmon 计数器，但我\xe2\x80\x99 从未见过这些计数器被填充。也许它们需要跟踪非常高的观察者开销，在这种情况下它们可能隐藏在跟踪标志后面。
\n哇，如果这些驱逐率可用，我们\xe2\x80\x99d 可能会对 PLE 有很多了解。
\n