sql-server – CPU利用率是否影响外国NUMA访问的成本？

任务分配还有一些其他细微差别.但主要的好处是CPU忙不一定会在NUMA节点上均匀分布.
(同样很好地意识到bpool页面插入(读取或首页写入)将进入与工作者所在的调度程序相关联的SQLOS内存节点中的bpool.被盗页面将优先来自“本地”SQLOS内存节点也是.

我发现将maxdop从0增加到不超过8是有帮助的.根据工作负载配置文件(主要是关于并发预期的可能长时间运行的查询的数量),可能需要一直到MAXDOP = 2.

调整并行度的成本阈值也可能有所帮助.我工作的系统倾向于使用高成本查询,很少遇到50或100以下的计划,所以通过调整maxdop(工作负载组级别)来调整成本阈值,我有更多的牵引力.

> SQL Server PLE with 8 NUMA nodes

在这篇文章中,讨论了围绕工作空间内存和不均匀任务分布的螺旋锁争用的组合.看 – 这些东西真的一起编织在一起:-)
> 40 concurrent SQL Server parallel queries + (2 sockets * 10 cores per socket) = spinlock convoy

> bpool中的相关数据放置

这是我认为在处理NUMA服务器时最直观的条件.通常,它对工作负载性能也不是非常重要.

如果将表读入NUMA节点3上的bpool,然后NUMA节点4上的查询扫描执行NUMA节点上所有bpool查找的表,会发生什么？

Linchi Shea在这个性能影响方面有很好的帖子：

> http://sqlblog.com/blogs/linchi_shea/archive/2012/01/30/performance-impact-the-cost-of-numa-remote-memory-access.aspx

跨NUMA节点访问内存会产生少量额外的内存延迟.我确信有些工作负载需要消除额外的基本内存延迟以获得最佳性能 – 这在我使用的系统上不是问题.

但是 – 跨节点访问还带来了另一个可能潜在饱和的转移点.如果存在如此多的活动以致NUMA节点之间的存储器带宽饱和,则节点之间的存储器延迟将增加.同样的工作需要额外的CPU周期.

再次 – 我确信存在工作负载,以至于内存带宽是一个关键考虑因素.但是,对于我的系统,我列出的其他考虑因素更为重要.

>物理内存放置

这个很少见,但重要的是,这真的很重要.在大多数服务器上,内存安装几乎自然会在NUMA节点之间取得平衡.但在某些情况下,需要特别注意平衡节点之间的内存.如果内存以不平衡的方式插入,某些系统的性能可能会完全被破坏.尽管如此,这是设置 – 忘记它.在经过数月的生产服务而不是在第一个真正忙碌的一天之后发现这样的问题非常罕见:-)

大完成！

其他人指出,糟糕的计划选择,可能是由于过时的统计数据,可能会导致你所看到的症状.根据我的经验,情况并非如此.糟糕的计划很容易使查询花费的时间比预期的要长 – 但通常是因为执行的逻辑IO比必要的多.或者由于溢出到tempdb.在观察服务器时,对tempdb的大量泄漏应该是明显的 – 而不是高CPU会期望与溢出相关的磁盘写入的可测量的等待时间.

相反,如果您观察到的情况与NUMA相关,我希望它是上面列举的因素的组合,主要是：

>使用工作区内存(不会显示在逻辑IO计数中)>由于持久的外部内存条件,可能是跨NUMA节点(如果是这种情况,请查找相关修复)>每次针对授权进行分配时,可能会在NUMA节点内发生螺旋锁争用(使用T8048修复)>并且可以由其他并行查询工作者超载的逻辑CPU上的工作人员执行(根据需要调整maxdop和/或并行度的成本阈值)

（编辑：PHP编程网 - 黄冈站长网）

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