流言终结者12之tempdb总是应当创建和CPU内核数一样多的文件吗？

流言终结者12之tempdb总是应当创建和CPU内核数一样多的文件吗？

原文：A SQL Server DBA myth a day: (12/30) tempdb should always have one data file per processor core

原文链接：

http://www.sqlskills.com/BLOGS/PAUL/post/A-SQL-Server-DBA-myth-a-day-%281230%29-tempdb-should-always-have-one-data-file-per-processor-core.aspx

译文：

答案：错。

1. 前言

唉，这是我听到的最让人头疼的流言，因为有很多微软的“官方”信息以及很多博文都坚持这种观点。

最让人混淆的是SQL CAT小组也建议1:1，但是他们是从按比例缩放角度（scaling perspective），而不是从性能角度(perf perspective)得出的。他们接触的都是些拥有超级服务器和IO子系统的大客户，但我们普通人却没有。

每个数据库实例只有一个tempdb，有很多方面会用到它，所以它常常是性能的瓶颈。这些你们可能早就知道了，但是何时应该创建额外的数据文件来解决性能问题呢？

2. 何时需要创建额外的数据文件？

当你看到tempdb中有PAGELATCH时，说明你的分配位图已经开始有竞争了。当你看到tempdb中有PAGEIOLATCH时，说明你的IO子系统已经开始有竞争了。你可以将闩（LATCH）看作是一种事务锁，但是更轻、更短暂，由存储管理器内部用来存取内部结构（比如内存中的数据页）用的。

Glenn Berry有一篇博文介绍了几个使用sys.dm_os_wait_stats视图的脚本——第一个脚本可以列出服务器上最多的等待类型。如果你看到PAGELATCH等待，你可以使用Robert Davis（MCM、微软DBA）的这个脚本。它是使用了sys.dm_os_waiting_tasks视图将各种等待资源分开，让你了解哪些是在tempdb上的。

如果你看到tempdb上有PAGELATCH等待，你可以使用跟踪标志TF1118（完整介绍见KB328551）以及创建更多的tempdb数据文件来缓解这种状况。我曾写过一篇文章澄清一些关于这个跟踪标志的流言以及为什么这个标志在SQL 2005和2008中还继续存在。

3. 需要增加多少文件？

对于SQL SERVER 2000，建议是CPU内核数和tempdb数据文件数是1:1。但是2005和2008，这个建议还在，但是由于进行了优化（见我的文章），所有就不需要1:1了——数据文件数和CPU内核数比例为1/4到1/2就可以了。

这是一个傻瓜式大概的结论（，并不是说一定就得按这个做）。上周我就听我的一个客户说，由于他们的tempdb负载很大，他们竟然在一个32核心的系统上建了64个tempdb文件——这是他们唯一可用来缓解竞争的方法。但是能说这种方法最实用的吗？绝对不。

4. 为什么不在需要1:1？

那为什么说1:1并不总是一个好方法呢？太多的tempdb数据文件会致性能问题还有另外一个原因。如果你有一个需要大量内存的查询计划操作（比如排序），但是你的服务器中没有那么多内存，那么就必须将部分脏页写到tempdb磁盘数据文件中。此时如果有太多的文件，因为分配系统需要循环（Round-robin）分配，所以实际上会降低速度。这种情况也会发生在tempdb上的超大临时表上。

为什么循环分配会降低写到多个tempdb文件上的速度呢？有下面几种可能性：

· 循环分配发生于每个文件组，tempdb中只能有一个文件组。当tempdb文件组中有16、32或更多的文件，并从几个线程中进行非常大的分配时，额外的同步和进行循环分配的一些必要工作（比如，查看每个文件的分配加权值，然后决定是进行分配还是减少加权值，还会相当频繁（每8192个分配单元）地为每个文件重新计算加权值）开始增加并且不容小觑。这和从多个线程中进行多个小分配不同，这也和从单文件中分配不同——很显然，这将经过优化系统从而不进行循环分配。

· 假如你的tempdb数据文件不一样大，这样自动增加将会只是增加单个文件（非常不幸算法就这样（the algorithm is unfortunately broken）），导致畸形使用和IO热点。

· 当系统中缓冲区不大但是tempdb异常巨大，那么就会需要通过lazywriter来释放缓冲区时，此时拥有过多的文件是导致随机IO模式根本原因（tempdb的检查点是不会写数据脏页的）。如果IO子系统不能处理这种跨多个文件的加载，那么系统开始变慢了。

我真想写篇关于这方面性能测试文章来说明我的意思。但是，我已从我的多个客户（他们创建了大量tempdb文件）那儿听说了这些。而且我知道这些原因还因为我知道代码是如何工作的（我们开发小组曾经拥有分配系统的源码）。

5. 总结

如果你这样做也不对，不过也不对，是吗？可能是吧。这给你出了个难题，tempdb到底要有多少文件呢？呵呵，我不能给你一个准确答案，我只能基于我和多个客户的交谈及会议/课程给你一些指导。对于只是通过创建多个tempdb文件来缓解竞争一定要小心——除非你很清楚，否则不要创建太多文件——如果你真这样做了，你一定得知道它的缺点。你可以在扩展性和性能之间有个平衡点，以避免帮了一个而坏了另一个。

6. 附一篇评论

不，额外的文件不需要放到独立的存储上。如果你只是看到PAGELATCH竞争，那么放在独立的存储对内存分配位图竞争没有任何用。对于PAGEIOLATCH等待，你最好使用独立的存储，但是也不是必须的——你可以将tempdb数据库和其他数据库储存分开，而不是增加更多的数据文件。分析存储的东西从而选择正确的途径。