加入收藏 | 设为首页 | 会员中心 | 我要投稿 核心网 (https://www.hxwgxz.com/)- 科技、建站、经验、云计算、5G、大数据,站长网!
当前位置: 首页 > 编程 > 正文

sql-server – 分配更多CPU和RAM后,SQL Server性能降低

发布时间:2021-01-11 01:05:48 所属栏目:编程 来源:网络整理
导读:我们在虚拟 Windows 2008 R2服务器上运行SQL Server 2008 R2(10.50.1600).在将CPU从1核升级到4并将RAM从4 gb升级到10 gb后,我们发现性能更差. 我看到一些观察结果: 花费5秒运行的查询现在花费 200秒. CPU被钉在100,sqlservr.exe是罪魁祸首. 具有460万行的表

我们在虚拟 Windows 2008 R2服务器上运行SQL Server 2008 R2(10.50.1600).在将CPU从1核升级到4并将RAM从4 gb升级到10 gb后,我们发现性能更差.

我看到一些观察结果:

>花费<5秒运行的查询现在花费> 200秒.
> CPU被钉在100,sqlservr.exe是罪魁祸首.
>具有460万行的表上的选择计数(*)花费超过90秒.
>服务器上运行的进程未更改.唯一的变化是增加cpu和ram.
>其他sql服务器有一个静态页面文件,其中此服务器设置为自己管理它.

有没有人遇到过这个问题?

每个sp_BlitzErik,我跑了

EXEC dbo.sp_BlitzFirst @SinceStartup = 1;

给我这些结果.

解决方法

这里有很多,其中大部分都是相当广泛和模糊的.

> 2008R2 RTM于2010年4月21日问世.它完全没有支持.您需要优先使用最新的Service Pack,该服务包大约在3年前发布.这样,如果你遇到一个奇怪的错误或其他什么,你将被覆盖.赶上over here,找出你需要下载的内容.
>由于您添加了vCPU(从1到4)并且未更改任何设置,因此您的查询现在可以并行.我知道这听起来好像他们都会更快,但坚持下去!
>您可能已添加了RAM,但您可能没有更改Max Server Memory,因此您的服务器可以利用它.
>找出服务器正在等待的内容.我工作的公司编写免费脚本来帮助您测量SQL Server.如果您想尝试一下,请前往over here.

你想抓住sp_BlitzFirst检查服务器的等待统计数据.你可以用几种方式运行它.

这将显示您的服务器自启动以来一直在等待的内容.

EXEC dbo.sp_BlitzFirst @SinceStartup = 1;

这将显示在30秒窗口期间现在正在等待的查询.

EXEC dbo.sp_BlitzFirst @Seconds = 30,@ ExpertMode = 1;

一旦你弄清楚正在等待什么查询(有很多关于等待统计数据的东西),你可以开始做出改变以控制事情.

如果你看到他们在CXPACKET上等待,这意味着你的查询是平行的,并且可能互相践踏.如果你点击这个,你可能会考虑将并行度的成本阈值提高到50,并且可能会将MAXD??OP降低到2.

在此步骤之后,您希望使用类似sp_WhoIsActive或sp_BlitzWho(后者在之前的GitHub repo中)的内容来开始捕获查询计划.除了等待统计数据,它们是你可以看到的最重要的事情之一,以找出出错的地方.

您可能还想查看Jonathan Kehayias关于SQL Server的文章,了解VMWare Counters.

更新

回顾等待数据和男孩他们很奇怪. CPU确实存在一些问题.你的服务器大多坐在无聊的地方,但是当事情升温时,事情会变得糟糕.我会试着轻易地解决这个问题.

>你正在打一个叫做THREADPOOL的poison wait.你没有它,但这是有道理的,因为你的服务器不是非常活跃.我会在一分钟内解释原因.
>你在SOS_SCHEDULER_YIELD和CXPACKET上有很长的平均等待时间.你在虚拟机上,所以你要确保SQL Server有保留,或者盒子没有可怕的超额订阅.吵闹的邻居真的会毁了你的一天.您还需要确保服务器/ VM guest虚拟机/ VM主机未在Balanced Power模式下运行.这会使您的CPU降低到不必要的低速,并且它们不会立即回升到全速.
>他们如何配合?使用4个CPU,您有512个工作线程.请记住,你有一个单CPU的same amount,但现在你的查询可以并行,他们可以消耗更多的工作线程.在你的情况下,并行查询的每个并行分支4个线程.

什么是平行的?最有可能的一切. Parallelism的默认成本阈值是5.这个数字在90年代后期的某个时间是默认值,在桌面上工作like this.

当然,你的硬件比大多数笔记本电脑都小,但你仍然领先于那件事.

当大量并行查询开始运行时,您将耗尽这些工作线程.当发生这种情况时,查询只是等待线程开始.这也是SOS_SCHEDULER_YIELD的用武之地.查询是踩掉CPU而不是长时间重新开启.我没有看到任何阻塞等待,所以你很可能只是在查询内并行等待的所有内容.

你能做什么?

>确保没有任何东西处于平衡电源模式
>将MAXD??OP更改为2
>将并行度的成本阈值更改为50
>按照上面的Jon K.文章来验证VM运行状况
>使用名为sp_BlitzIndex的GitHub仓库中的脚本查找任何缺失的索引请求.

有关更全面的故障排除,请查看有关云中硬件大小的whitepaper I wrote for Google.

希望这可以帮助!

(编辑:核心网)

【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容!

    热点阅读