有兴趣听取其他人发现跟踪标志8048(从每个NUMA节点到每个核心提升查询内存授予策略),跟踪标志8015(sql Server忽略物理NUMA)或SUMA(通过跟踪标志8048提供性能值)的用例.交错充分统一的内存访问,某些NUMA机器上的BIOS选项).
系统工作负载的细节,来自故障系统的收集指标,以及干预后从系统收集的指标.
跟踪标志8048是一个’修复’,但它是最好的修复？由于跟踪标志8015,sql Server忽略物理NUMA会完成同样的事情吗？如何将BIOS设置为交错内存,让服务器模仿SMP模仿SUMA行为而不是NUMA行为？
和平！
tw：@sql_handle
关于系统：
– 4个六核Xeon E7540 @ 2.00GHz,超线程
– 128 GB RAM
– WS2008R2
– MSsql 2008 R2 SP2
– maxdop 6
关于工作量：
– 从2个报告应用程序服务器驱动的1000个批量计划/排队报告.
– 3种口味的批次：每日,每周,每月
– 所有报表应用程序服务器与sql Server的连接都是作为单个服务帐户建立的
– 最大报告并发度= 90
陷入困境的系统的主要发现：
– 来自Perfmon,间隔15秒
– – 系统保持在95％-100％cpu忙
– – sql Server缓冲区页面查找< 10000 /秒
>从等待和螺旋锁DMV,每隔5分钟
>
>高CMEMTHREAD服务员和等待时间
>
>高SOS_SUSPEND_QUEUE旋转和后退
Bob Dorr的CSS工程师关于跟踪标志8048的博客文章表明,由于查询内存授予的瓶颈,每个NUMA节点具有超过8个核心的系统可能会遇到类似的症状.跟踪标志8048将策略更改为每核心而不是每NUMA节点.
干预
使用-T8048重新启动MSsql.差异立即显而易见：缓冲区页面查找率上升超过100万,飙升至每秒800万.以前无法在24小时内完成的故障批处理工作量在不到4小时内完成.作为验证痕量标志8048的校正值(并确保其不必要的副作用最小)的一部分,提交了另一个不是调查或干预重点的批量工作量.此报告批次先前在2小时内完成;跟踪标志8048到位,报告批量大约在20分钟内完成.
夜间ETL也遇到了好处. ETL时间从大约60分钟下降到40分钟.
从几个地方汇集信息,我推测报告排队的高度,并发报告计数大于硬件线程数,并且所有报告的单个用户帐户组合起来对一个NUMA节点施加压力,直到工作线程压力导致它对于同一用户帐户的下一个传入连接请求是不受欢迎的,此时下一个NUMA节点将立即获得一些连接数.每个NUMA节点最终都有可能强调查询内存授予瓶颈.
为查询内存授予打开更多通道消除了瓶颈.但是,我不确定成本. Bob Dorr的CSS帖子清楚地表明跟踪标志8048存在额外的内存开销.单页分配器区域内的开销是否受MSsql 2008 R2最大服务器内存的控制？如果是这样,我想系统只会在缓冲池缓存中减少一些数据库页面.如果没有,是否应降低最大服务器内存以容纳？
解决方法
为了回答你的最后一个问题,我推测你的回答是“是”.
也就是说,在使用跟踪标志之前,我可能会追求软numa.我认为你对numa节点的分配是正确的,这可能是你问题的根源.通过软numa,您可以扩展请求,具体取决于您的numa节点数(4？) – 4,如果这是正确的数字,然后通过IP地址将每个主机分配给特定的numa节点,此外为此,我将禁用超线程.合并后,问题可能会减少,但是,它会以较少的调度程序为代价.
在一个单独的想法,我会看到强制参数化 – 你的负载驱动你的cpu如此之高的事实是非常有趣的,它可能值得研究.
最后,在多numa节点系统上,我通常将以下查询的输出每N秒转储到一个表中.在实现工作负载更改或跟踪标志时进行一些有趣的分析：
SELECT getdate() as poll_time,node_id,node_state_desc,memory_node_id,online_scheduler_count,active_worker_count,avg_load_balance,idle_scheduler_count FROM sys.dm_os_nodes WITH (NOLOCK) WHERE node_state_desc <> N'ONLINE DAC'
和
SELECT top 10 getdate() as sample_poll,wait_type,count (*)
FROM sys.dm_os_waiting_tasks
WHERE [wait_type] NOT IN
('CLR_SEMAPHORE','LAZYWRITER_SLEEP','RESOURCE_QUEUE','SLEEP_TASK','SLEEP_SYSTEMTASK','sqlTRACE_BUFFER_FLUSH','WAITFOR','BROKER_TASK_STOP','BROKER_RECEIVE_WAITFOR','OLEDB','CLR_MANUAL_EVENT','CLR_AUTO_EVENT' )
GROUP BY wait_type
ORDER BY COUNT (*) DESC
