假设我有一个带有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时间：
许多其他活动会占用大量的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节点内存分配的行为.发生这种情况时,性能影响可能是毁灭性的.
针对持久性跨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节点努力工作而其他人正在闲逛.
任务分配还有一些其他细微差别.但主要的好处是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在这个性能影响方面有很好的帖子：
跨NUMA节点访问内存会产生少量额外的内存延迟.我确信有些工作负载需要消除额外的基本内存延迟以获得最佳性能 – 这在我使用的系统上不是问题.
但是 – 跨节点访问还带来了另一个可能潜在饱和的转移点.如果存在如此多的活动以致NUMA节点之间的存储器带宽饱和,则节点之间的存储器延迟将增加.同样的工作需要额外的cpu周期.
再次 – 我确信存在工作负载,以至于内存带宽是一个关键考虑因素.但是,对于我的系统,我列出的其他考虑因素更为重要.
>物理内存放置
这个很少见,但重要的是,这真的很重要.在大多数服务器上,内存安装几乎自然会在NUMA节点之间取得平衡.但在某些情况下,需要特别注意平衡节点之间的内存.如果内存以不平衡的方式插入,某些系统的性能可能会完全被破坏.尽管如此,这是设置 – 忘记它.在经过数月的生产服务而不是在第一个真正忙碌的一天之后发现这样的问题非常罕见:-)
大完成！
其他人指出,糟糕的计划选择,可能是由于过时的统计数据,可能会导致你所看到的症状.根据我的经验,情况并非如此.糟糕的计划很容易使查询花费的时间比预期的要长 – 但通常是因为执行的逻辑IO比必要的多.或者由于溢出到tempdb.在观察服务器时,对tempdb的大量泄漏应该是明显的 – 而不是高cpu会期望与溢出相关的磁盘写入的可测量的等待时间.
相反,如果您观察到的情况与NUMA相关,我希望它是上面列举的因素的组合,主要是：
>使用工作区内存(不会显示在逻辑IO计数中)>由于持久的外部内存条件,可能是跨NUMA节点(如果是这种情况,请查找相关修复)>每次针对授权进行分配时,可能会在NUMA节点内发生螺旋锁争用(使用T8048修复)>并且可以由其他并行查询工作者超载的逻辑cpu上的工作人员执行(根据需要调整maxdop和/或并行度的成本阈值)
