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

脚本

假设我有一个带有4个套接字的SQL Server,每个1个NUMA节点.每个插槽有4个物理内核.总共有512 GB的内存,因此每个NUMA节点有128 GB的RAM.

密钥表被加载到第一个NUMA节点中.

题

假设我们从该表中读取了大量流量.如果拥有NUMA节点的套接字的所有物理内核具有100％的CPU利用率,那是否会对来自其他套接字的非本地NUMA访问的成本产生负面影响？或者另一方面,非本地NUMA访问的成本与套接字的繁忙程度无关？

我希望我的问题有道理.请告诉我,如果不是,我会尽力澄清.

背景

我们上周在我们的生产服务器中遇到了数据库问题,我们处理的一些业务似乎比其他业务更受影响.我们查询的逻辑读取次数超过1分钟.我们查看了整体CPU利用率约为60％.我们没有查看特定于套接字的CPU指标. I / O指标是平均值.

解决方法

对不起,我无法缩短这个……

>累计CPU ms与逻辑IO
> SQL Server逻辑内存节点与物理NUMA节点对齐
>查询工作区内存分配中的Spinlock争用
>调度程序的任务分配
>缓冲池中的相关数据放置
>物理内存放置

>累计CPU ms与逻辑IO

我经常使用逻辑IO的图形(或在perfmon术语“缓冲池页面查找”中)来反对CPU利用率,以便衡量工作负载的CPU效率并查找易于发生螺旋锁的情况.

但是,除了页面查找和自旋锁之外,SQL Server还会累积大量活动的CPU时间：

>计划编制和重新编制.
>执行CLR代码.
>执行功能.

许多其他活动会占用大量的cpu时间,而不会在页面查找中反映出来.

在我观察到的工作负载中,这些“非逻辑IO密集但CPU吞噬”活动中的主要活动是排序/散列活动.

这是有道理的：考虑一个针对没有非聚簇索引的哈希表的两个查询的人为举例.这两个查询具有相同的结果集,但其中一个结果集完全无序,第二个结果集按多个选定列排序.第二个查询将占用更多的CPU时间,即使它将引用缓冲池中相同数量的页面.

有关工作区内存的更多信息,以及已使用的已授权工作区的数量,请参阅以下帖子：

> http://sql-sasquatch.blogspot.com/2015/08/sql-server-grantedreservedstolen_4.html
> http://sql-sasquatch.blogspot.com/2015/08/sql-server-workspace-memory-with-twist.html
> http://sql-sasquatch.blogspot.com/2015/03/resource-governor-to-restrict-max-query.html

> SQL Server逻辑内存节点与物理NUMA节点对齐

默认情况下,SQL Server(因为合并了其NUMA感知策略)为服务器上的每个NUMA节点创建一个SQLOS内存节点.随着内存分配的增长,每个分配都由一个SQLOS内存节点控制.

理想情况下,SQLOS内存节点与物理NUMA节点完全对齐.也就是说,每个SQLOS内存节点包含来自单个NUMA节点的内存,没有其他SQLOS内存节点也包含来自同一NUMA节点的内存.

但是,理想的情况并非总是如此.

以下CSS SQL Server Engineers博客文章(也包含在Kin的响应中)详细说明了可能导致SQLOS内存节点的持久交叉NUMA节点内存分配的行为.发生这种情况时,性能影响可能是毁灭性的.

> http://blogs.msdn.com/b/psssql/archive/2012/12/13/how-it-works-sql-server-numa-local-foreign-and-away-memory-blocks.aspx

针对持久性跨NUMA节点引用的特别痛苦的情况进行了一些修复.除了这两个之外,可能还有其他人：

> FIX: Performance problems occur in NUMA environments during foreign page processing in SQL Server 2012 or SQL Server 2014
> FIX: SQL Server performance issues in NUMA environments

>分配工作空间内存期间的Spinlock争用

这是它开始变得有趣的地方.我已经描述了工作空间内存中的排序和散列工作消耗CPU,但没有反映在bpool查找号中.

Spinlock争用是这个特殊乐趣的另一层.当内存从缓冲池中被盗并分配用于查询内存授权时,内存访问将使用自旋锁序列化.默认情况下,这是使用在NUMA节点级别分区的资源进行的.因此,使用工作空间内存在同一NUMA节点上的每个查询都可能在针对授权窃取内存时遇到螺旋锁争用.非常重要的是要注意：这不是“每次查询一次”的争用风险,因为如果争用点是在实际授权时.更确切地说,当内存在授权中被盗时 – 如果使用大部分授权,具有非常大的内存授权的查询将有很多机会进行螺旋锁争用.

通过在核心级别进一步划分资源,跟踪标志8048可以很好地缓解这种争用.

微软称“如果每个插槽有8个或更多核心,则考虑跟踪标志8048”.但是……并不是每个插槽有多少核心(只要有多个核心),而是在单个NUMA节点上完成工作的争用机会有多少.

在胶合的AMD处理器上(每个插槽12个内核,每个插槽2个NUMA节点),每个NUMA节点有6个内核.我看到一个系统中有4个CPU(因此有8个NUMA节点,每个6个核心),它们在自旋锁队列中被卡住,直到跟踪标??志8048被启用.

我已经看到这个螺旋锁争用将虚拟机上的性能降低到4个vCPU.跟踪标志8048执行了在这些系统上启用时应该执行的操作.

考虑到仍有大约4个核心频率优化的CPU,在正确的工作负载下,它们也受益于跟踪标志8048.

CMEMTHREAD等待跟踪标志8048释放的螺旋锁争用类型.但需要注意的是：CMEMTHREAD等待是一个确凿的症状,而不是这个特定问题的根本原因.我已经看到系统具有高CMEMTHREAD“等待启动”,其中跟踪标志8048和/或9024在部署中被延迟,因为累积的CMEMTHREAD等待时间相当低.使用自旋锁,累积等待时间通常是错误的.相反,您希望查看浪费的CPU时间 – 主要由旋转本身表示,其次是相关的等待,表示可能不必要的上下文切换.

> How It Works: CMemThread and Debugging Them

>调度程序的任务分配

在NUMA系统上,假设没有与特定NUMA节点相关联的连接端点,则将连接分发到NUMA节点(很好 – 实际上是与它们相关联的SQLOS调度程序组)循环.如果会话执行并行查询,则强烈倾向于使用来自单个NUMA节点的工作程序.嗯……考虑一个4 NUMA节点服务器,其复杂查询分为4个路径,默认为0 MAXDOP.即使查询仅使用MAXDOP工作线程,NUMA节点上的每个逻辑CPU也会有4个工作线程.但是复杂计划中有4条路径 – 因此NUMA节点上的每个逻辑CPU都可以有16个工作程序 – 所有这些都用于单个查询！

这就是为什么有时候你会看到一个NUMA节点努力工作而其他人正在闲逛.

（编辑：衡阳站长网）

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