为什么tempdb的io_stall_writes_ms这么高？

我们将用户和系统数据文件放在同一磁盘驱动器上。用户文件的（io_stall_write_ms /（1.0 + num_of_writes））低于2，但是tempdb文件通常超过400。而不是常规的数据库数据文件。

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]

谢谢，

简短的答案：看到更高的IO停滞本身可能不是问题。您需要查看更多信息以解决问题。好像有点高，是的，但是您在受苦吗？如果是这样，可能是因为您的IO系统未处理正确的负载（因为它无法处理，因为您将所有内容都放在一个驱动器上或其他原因）或您在TempDB中做的太多（改变了第一个问题- IO性能-可能是更简单，更有效的修复方法，但请先确定您是否遇到问题）

较长的讨论/答案：

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

1.）当我看到高IO失速时该怎么办？

首先，“高”在情人眼中。如果您要问10个DBA，IO停顿的“过高”是什么，您可能会得到2-3个不同的答案，其中包含数字，5-6个“取决于”答案和一个空白的凝视。我的假设是，此处平均400ms可能太高，尤其是在其他DBs的平均停顿时间小于2ms时。

无论哪个数据库出现高停顿，您都应该以相同的方式处理它。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/Readand Avg Sec Disk Sec/Write计数器。这些衡量您的延迟。观察这些计数器在一段时间内保存到性能日志文件中的情况。您平均看到了什么？如果看到的数字超过0.020秒（20毫秒），则可能是一个问题。如果您看到平均值超过40-50ms或更高的数字，则更能确定问题。还要看看你的峰值吗？他们走了多高，持续了多长时间？如果您看到峰值达到几百毫秒，并且持续数十秒或数十秒甚至更长，并且/或者经常发生，那么您的IO性能可能会遇到问题。
3. 查看您的IO设置。它是什么？本地磁盘？SAN？存储阵列？您应该从中看到什么样的结果和IOP？这足以满足您的需求吗？您可能无法充分利用IO的工作量。不要只看您的物理主轴，RAID设置等。而是看您的磁盘路径。您是否正在通过与多个其他流量共享的单个1GB链接推送所有内容？您能从存储的角度看磁盘性能指标吗？

（注意：对于此等待统计信息分析和性能分析-查看不同时段和使用情况类型。晚上使用的统计信息与白天不同吗？批处理窗口？在其中维护大量索引的维护窗口？在每个阶段中查看这些工具，并了解每个阶段所看到的内容）

此处的另一个IO性能注意事项-

• 您说系统DB和用户DB是共享的。这是产品吗？如果是这样，那并不总是最好的情况。您是否还在同一驱动器上共享日志文件和数据文件？那也不是最好的情况。还有什么共享此存储空间？在一个您担心主轴，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. 您是否在系统中使用大量更新的“已提交读快照隔离”级别？这也可能导致TempDB活动增加。

关键是-TempDB的使用方式很多，将它视为您最繁忙的数据库之一（即使不是最繁忙的数据库）也丝毫不奇怪。当我看到它在客户端站点上的所有数据库中具有最多的平均停顿数时，也不会感到惊讶。有时这是其工作量的性质。查看我在这里提到的一些内容，可以肯定地帮助您确定这些数字是否表明存在问题，如果存在，那么如何进一步解决问题。

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具有四个以上的文件，我几乎看不到任何改进。因此，我通常从四开始，按照我所链接的文章中的说明监视争用。

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