SQL 性能 - 一个计数器来统治它们 - 识别 CPU/MEM/DISK/NET 压力

Question

作为一名 DBA，我已经对 SQL 服务器进行性能调优多年。

我正在尝试创建一个快餐版的性能指标，它可以快速（在 5 分钟内）和准确（可证明）回答来自管理层的问题“此服务器需要更多/更快 _ 吗？”

“_”是 IT 堆栈自下而上的这 4 个可能的瓶颈之一（从服务器的角度来看，无需进入应用程序/代码/用户界面）：

1. 网络

2. 磁盘

3. 记忆

4. 中央处理器

有数以千计的柜台、文章、产品可以帮助监控这些。但是是否有一个简单、即时和准确的脚本可以确定这 4 个中的任何一个是否需要扩大或缩小？

例如 sys.dm_os_wait_stats - SOS_SCHEDULER_YIELD 具有高信号等待 => 需要更多或更快的 CPU。
PAGEIO_LATCH => 需要更多文件或更快的磁盘

这2个准确吗？Page Life Expectancy 是否准确地“证明”了需要更多内存？您用于诊断性能问题的GO-TO脚本是什么？

我使用过 sp_whoisactive、sp_blitz、Glenn 的 DMV、Spotlight、Idera 等，但我还没有遇到一个脚本可以满足 CIO 关于在哪里花费预算资金的问题，或者将问题正确归咎于错误代码，或者速度缓慢SAN 或 ISP。

每当任何（网络/系统/DBA/应用程序）工程师指责另一个团队时，我们都必须“证明”我们的陈述，而有了虚拟化和云，没有理想的测试环境，没有停机时间，越来越难以证明地精确定位服务器性能问题的根源，可能是任务管理器以外的<请原谅咆哮>

Answer 1

不。假设您有一台服务器：

• 高 PAGEIOLATCH 等待
• 高 IO 停顿时间
• 低页面预期寿命（例如，始终低于 30）
• 128GB 内存

您可以使用以下方法修复此场景：

• 索引调整 - 因为查询可能正在扫描一个太大而无法放入内存的表
• 查询调优——因为他们可能使用了不可搜索的谓词，或者没有缓存
• 配置 - 因为也许有些怪人将最大服务器内存设置得太低，或者我们为我们的代码使用了错误的基数估算器
• 添加内存 - 但现在您必须检查版本和版本，因为您的 Windows 或 SQL Server 可能不支持更多内存
• 更快的存储 - 但这是一个昂贵的修复

没有一个指标可以告诉您哪些解决方案是正确的。欢迎使用性能调优。这不是一个简单的按钮。