为什么 io_stall_writes_ms 对于 tempdb 如此之高？

Question

我们在同一个磁盘驱动器上有用户和系统数据文件。( io_stall_write_ms / ( 1.0 + num_of_writes ) ) 对于用户文件低于 2，但 tempdb 文件通常超过 400。我在几台服务器上看到了这一点，我很好奇是否存在写入 tempdb 需要更长时间的原因比一个普通的数据库数据文件。

SELECT DISTINCT UPPER(LEFT(mf.physical_name, 1)) AS Directory,
( io_stall_write_ms / ( 1.0 + num_of_writes ) ) as result, 
io_stall_write_ms, num_of_writes, 
fs.database_id, 
fs.[file_id]
FROM sys.dm_io_virtual_file_stats(NULL, NULL) AS fs
INNER JOIN sys.master_files AS mf ON fs.database_id = mf.database_id
AND fs.[file_id] = mf.[file_id]

谢谢，

Answer 1

简短回答：看到更高的 IO 停顿本身可能是也可能不是问题。如果您有问题，您需要查看更多信息来确定。它看起来确实有点高，是的，但是你在受苦吗？如果是这样，这可能是因为您的 IO 系统没有正确处理负载（因为它不能正确处理负载，因为您将所有内容都放在一个驱动器上或其他原因），或者您在 TempDB 中做得太多（改变第一个问题 - IO 性能 - 可能是一个更容易和更有效的修复，但首先确定你是否有问题）

更长的讨论/答案：

这里有两个问题在起作用——

1.) 当我看到高 IO Stalls 时我该怎么办？

首先，“高”在旁观者的眼中。如果您要问 10 位 DBA，IO 停顿“太高”是什么意思，您可能会得到 2-3 个不同的答案，其中包含数字，5-6 个“视情况而定”的答案和一个茫然的凝视。我的假设是这里的平均 400 毫秒可能太高了，尤其是当其他 DB 的平均停顿时间为 2 毫秒或更低时。

无论哪个数据库看到高位，您都应该以相同的方式处理它。IO 停顿就是它听起来的样子... IO 请求花费的时间比预期的要长.. 停顿。这些发生。它们一直发生在资源共享且资源有限的系统中（实际上是我们所有的系统）。当停顿成为性能问题或导致它们时，它们就会成为问题。因此，我相信您将此处视为监控的主动部分，或者因为您遇到了正在排除故障的性能问题。我们也不想迷失在 IO 停顿中。我们正在研究拼图的一部分，而不是大局。自 SQL 上次重新启动以来，只查看等待统计数据或文件统计数据可能会很麻烦，因为您一直在查看，并且某些维护窗口或重负载窗口可能会使计数器倾斜。因此，请务必查看完整图片。

但是，当我怀疑我有磁盘性能问题或在这样的查询中看到某些东西时，我通常会遵循如下流程：

1. 查看服务器上的等待统计信息。@swasheck在下面的答案中分享了一个很好的链接作为评论。这会将您带到 Paul Randal 的关于查看和分析 SQL Server 中的等待统计信息的帖子。去那里。你看到什么样的等待？你是否看到有关IO性能（等待PAGEIOLATCH_*，IO_COMPLETION，WRITELOG等？）。如果您这样做，则表明您有一些与 IO 相关的性能问题，就像 IO 停顿一样。但它在这里为您提供了另一种形式的协议。
2. 看IO性能。特别是，查看 perfmon 的内部Physical Disk:Avg Disk Sec/Read和Avg Sec Disk Sec/Write计数器。这些测量您的延迟。在保存到性能日志文件的一段时间内观察这些计数器。你看到的平均值是什么？如果您看到的数字超过 0.020 秒（20 毫秒），这可能是一个问题。如果您看到平均超过 40-50 毫秒或更高的数字，则更明确地表明存在问题。还看看你的尖峰？它们能爬多高，能持续多久？如果您看到数百毫秒的峰值并且它们持续数十秒或数十秒或更长时间和/或频繁发生，则您的工作负载的 IO 性能更有可能出现问题。
3. 看看你的 IO 设置。它是什么？本地磁盘？圣？存储阵列？您应该从中看到什么样的吞吐量和 IOP？是否足以满足您的需求？您的 IO 可能不足以满足您的工作负载。不要只查看物理轴、RAID 设置等。查看磁盘路径。您是否通过与许多其他流量共享的单个 1GB 链接推送所有内容？您能否从存储的角度查看磁盘性能指标。

（注意：对于这个等待统计分析和性能分析 - 查看不同时期和使用类型。晚上的使用统计与白天不同吗？批处理窗口？维护窗口重建大量索引？在每个时期查看这些工具并了解您所看到的每个工具）

这里的另一个 IO 性能考虑 -

• 你说系统数据库和用户数据库是共享的。这是生产吗？如果是这样，那并不总是最好的情况。您是否还在同一驱动器上共享日志文件和数据文件？这也不是最好的情况。还有什么共享这个存储？在一个您担心心轴、raid 组和磁盘并且必须决定谁获得性能最佳磁盘的世界中，我倾向于（作为一般经验法则......这在数据库世界中并不好但这往往是正确的）与我最快和最专注于 TempDB（更多关于下面的内容）一起使用，然后是日志文件，然后是数据文件。在 NetApp、Dell Equal Logic 或 EMC VNX 等设备上拥有大量磁盘的世界中，您没有

2.) TempDB 可能更高的一些原因是什么？

所以 TempDB 是一个数据库，它可以像我刚刚讨论的任何其他数据库一样有 IO 停顿。但是 TempDB 可以具有更高读取的一些原因是什么？（并非详尽无遗，我欢迎在编辑、其他答案或评论中添加或想法）-

1. 由于您的代码 - 您是否有意在代码中大量使用 TempDB？创建和销毁了很多临时表和表变量？像这样在 TempDB 中做很多事情？这不一定是好是坏，但您可能会查看并了解您有意的 TempDB 使用模式。
2. TempDB 是共享主力 - TempDB 是一个数据库，用作用户定义的临时对象以及整个 SQL 实例使用的各种工作表和操作的临时空间。有多少个用户数据库？您通常看到什么样的工作量？TempDB 是一种可供所有事物共享的资源。
3. 低效查询和内存不足 - 也许有些查询没有足够紧密地使用索引，或者正在执行大型扫描和排序操作。大型散列操作，服务器上的内存不足以满足这些操作。这些操作将作为幕后工作表“溢出”到 TempDB。有时这可以通过查看查询计划和索引或查询调整来避免。有时会发生（我发现在仓库工作负载上更是如此）。如果您有足够的内存，这会有所帮助，但这些查询有时仍会溢出。看看这个。
4. 您是否使用 Read Committed Snapshot Isolation level 和系统中的大量更新？这也可能导致 TempDB 活动增加。

关键是 - TempDB 以多种方式使用，将它视为您最繁忙的数据库之一，如果不是最繁忙的数据库，我一点也不感到惊讶。当我认为它在客户站点的所有数据库中拥有最多数量和最高平均档位时，我也不会感到惊讶。有时这是其工作量的性质。看看我在这里提到的一些事情肯定可以帮助您确定这些数字是否表明存在问题，如果是，则如何更深入地解决它。

Answer 2

TempDB 在实例上的所有数据库之间共享。因此，TempDB 中有时可能会出现某些页面的争用：SGAM、GAM和PFS。简而言之，这些页面跟踪到目前为止 TempDB 中使用的内容以及可用于新用途的空间。

通常，这是通过向 TempDB 添加多个数据文件来解决的。关于正确的数字有几种不同的理念，但所有人都同意你应该有多个。

以下是一些要运行的查询...

这将显示 TempDB 有多少个文件以及它们所在的位置。

-- tempdb layout
use tempdb
go
exec sp_helpfile
go

这将显示您有多少个 CPU 和核心。

-- cores and hyperthreading
select cpu_count, hyperthread_ratio 
from sys.dm_os_sys_info
go

这将显示您拥有多少个 NUMA 节点以及每个 NUMA 节点的核心数。

-- numa nodes and schedulers
select node_id, online_scheduler_count
from sys.dm_os_nodes
order by node_id
go

这将显示 TempDB 中哪些页面正在等待。

-- see if anything is waiting on tempdb
select * 
from sys.dm_os_waiting_tasks
where resource_description like '2:%'
go

这是一篇更深入地讨论页面争用问题的文章。

好的，现在是哲学部分......:-)

对于我自己来说，如果我在SMP系统上，我只需要与总核心数一半一样多的文件。

如果我在NUMA系统上，那么我只需要与每个 NUMA 节点的核心数一样多的文件。

但是，我很少看到 TempDB 拥有四个以上文件有任何改进。因此，我通常从四个开始并监视争用，如我链接的文章中所述。

如果我继续发现问题，那么我会再添加两个。再次检查，添加更多，然后重复，直到争用消失。