SQL Server 培训,有以下场景:
Azure VM,DS 系列机器上的 SQL Server,它有 32 GB 的 RAM
服务器具有以下性能条件:
- very high PAGELATCH_IO waits
- average Page Life Expectancy is 30
- nothing else is known
为了减少 PAGELATCH_IO 等待应该怎么做?
选择正确答案(只需选择一个):
- 添加更多 tempdb 文件
- 启用大页面支持
- 在内存中启用锁定页面
- 配置缓冲池扩展
训练说正确答案是1) add more tempdb files
我认为正确的答案是4) Configure buffer pool extensions
,基于:
- PLE is a number of seconds a page will stay in the buffer pool without removing
- PLE = 30 is too low, means high turnover in the buffer pool
- DS-series support Premium SSD drives, can place buffer pool extension on Premium SSD
但也可能是3) Enable lock pages in memory
基于此
https://sqlperformance.com/2014/06/io-subsystem/knee-jerk-waits-pageiolatch-sh
谁是对的——我、培训材料,还是你(你的选择)?
顺便说一句,不确定它们在 PAGELATCH_IO 下的含义,可能是 PAGEIOLATCH 或 PAGELATCH,我想答案取决于我们拥有的确切类型
您似乎没有完全准确地复制此处培训材料中的问题。
假设问题是关于 PAGELATCH_** 等待,并且锁定的页面在 tempdb 数据库中,那么这些等待可能是 tempdb 分配争用的常见迹象。最常见的解决方案是增加 tempdb 文件的数量。
请参阅此 Microsoft 支持文章:
减少 SQL Server tempdb 数据库中分配争用的建议
如果我们已经怀疑 tempdb 争用(因为闩锁等待),那么 PLE = 30 可能是由于 tempdb 使用量过大(如果您认为大量 tempdb 页面被加载到内存中并反复释放,从而导致 PLE 下降)。
因此,选项 1 很可能是正确答案,尽管需要更多信息来确认(例如,知道闩锁等待实际上是在 tempdb 中)。
假设性问题的问题是我们不能要求更多信息。我们也不能要求澄清(您的意思是 PAGELATCH_IO、PAGEIOLATCH 还是 PAGELATCH?)。
只看到 PAGEIOLATCH 和低 PLE 并不一定意味着它是 tempdb。如今,32 GB RAM 并不多,但我们对这种环境一无所知。我们正在等待 I/O,这就是我们所知道的。也许我们只是“需要”更多的内存?
在 tempdb 上抛出文件并不意味着我们做的 IO 更少。OTOH,如果它是我们正在等待的 PAGELATCH(与 PAGEIOLATCH 相比),在 tempdb 中,那么更多文件可能是“它”。
最后,我会说扔更多的内存或调整查询。建议的替代方案都不合理。
像这样的低质量问题往往会让我们感到困惑,如果我们试图认真对待它们的话。:-)