TempDB为什么要根据CPU数目来cpu决定电脑什么文件个数

来源：蜘蛛抓取(WebSpider) 时间：2016-12-13 04:14 标签： linux cpu数目
tempdb数据库简介及优化_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
tempdb数据库简介及优化
上传于||文档简介
&&t​e​m​p​d​b​数​据​库​简​介​及​优​化
你可能喜欢1588人阅读
&流言终结者12之tempdb总是应当创建和CPU内核数一样多的文件吗？&原文：原文链接：&译文：&答案：错。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（完整介绍见）以及创建更多的tempdb数据文件来缓解这种状况。我曾写过澄清一些关于这个跟踪标志的流言以及为什么这个标志在SQL 中还继续存在。3.&&&& 需要增加多少文件？对于SQL SERVER 2000，建议是CPU内核数和tempdb数据文件数是1:1。但是，这个建议还在，但是由于进行了优化（），所有就不需要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数据库和其他数据库储存分开，而不是增加更多的数据文件。分析存储的东西从而选择正确的途径。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：448114次
积分：5789
积分：5789
排名：第3432名
原创：88篇
译文：44篇
评论：141条
(1)(3)(2)(2)(1)(1)(1)(1)(1)(1)(4)(1)(2)(3)(1)(6)(10)(1)(1)(3)(2)(6)(3)(7)(2)(4)(14)(1)(6)(2)(5)(2)(2)(3)(4)(1)(9)(1)(2)(2)(1)(1)(1)(2)(4)(3)tempdb这个系统数据库大家都很熟悉，很多新手对tempdb都是不去操作，而使用它的默认配置。
这其实并没有错，但是在追求性能之上的情况下，可以考虑对tempdb的配置进行修改。
服务器配置：
系统：win2008
数据库：sqlserver2008 R2&
CPU：24核，
内存：224GB，其中168GB给数据库使用，
硬盘：4块15000转机械硬盘组成raid5阵列。
服务器使用情况：
IO平均队列在5以下，高峰值在50左右，但不会持续2分钟以上，
CPU平均占用率在15%以下，高峰不超过50%，持续时间不过程30秒，
缓存页面生存周期按天算。
以下是本人执行的一个脚本，
在这里我们可以清晰的发现，tempdb所占的缓存为33695MB。
实际上，大多数服务器上，tempdb所占的空间不会超过2GB。这是什么问题造成的？
由于没有保存原有的tempdb的默认配置下，
当时tempdb只有一个主文件，有160GB左右，占用100多GB内存。
不过大家可以看我以前发布的一个帖子，这个帖子是我第一次遇到tempdb异常时，做的处理。
地址是：http://bbs.csdn.net/topics/
后来在黄sir的提醒下，以及我查阅了很多资料，对tempdb进行了处理。
tempdb有6个数据文件，一个日志文件，每个数据文件大小为10GB，日志文件为5GB。
然后tempdb占用的缓存一直保持在20GB左右，最近由于tempdb的文件再次增长，文件大小如下：
于是乎，tempdb在内存中占用的大小就增加了10GB。
网上大多数对tempdb的设置都是按CPU核数来设置tempdb的文件个数，
我这里采用的是24核CPU/6个数据文件，按4：1的比例来设计的。
从上面的分析，我得出来的结论是：
1、tempdb单个文件越大，如果内存富余，在内存中占用的缓存就越大(也有可能是不准确的，因为这仅仅是我接触一个场景)
2、tempdb单个文件越大，如果内存刚好或已经出现瓶颈，那么内存中的交换就越频繁，这会间接造成IO队列上升。
这是本人遇到的一个场景，然后根据场景所得出的结论，因为没有尝试验证其它的场景，所以得出的观念可能很片面，
但我希望能帮助到大家。
如果有别的看法，欢迎大家交流。
阅读(...) 评论()

我要回帖

更多关于 linux cpu数目 的文章

 

随机推荐