SQL Server-是否有人使用SUMA，跟踪标志8048或跟踪标志8015？

最近包括SQL Server启动跟踪标记8048，以解决SQL Server 2008 R2系统中的严重自旋锁争用问题。

希望听到其他人发现使用情况的情况，其中使用情况是通过跟踪标志8048（将查询内存授予策略从每个NUMA节点升级到每个核），跟踪标志8015（SQL Server忽略物理NUMA）或SUMA（交错访问足够均匀的内存（在某些NUMA计算机上为BIOS选项）。

跟踪标记8048 http://blogs.msdn.com/b/psssql/archive/2011/09/01/sql-server-2008-2008-r2-on-newer-machines-with-more-than-8-cpus每个数字节点可能需要跟踪标志-8048.aspx

跟踪标记8015 http://blogs.msdn.com/b/psssql/archive/2010/04/02/how-it-works-soft-numa-io-completion-thread-lazy-writer-workers-and-memory -nodes.aspx

详细的系统工作负载，从出现问题的系统收集的指标以及在干预后从系统收集的指标。

跟踪标志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）在跟踪标记8048上的CSS工程师博客文章中指出，由于查询内存授予的瓶颈，每个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驱动得如此之高的事实非常有趣，值得对此进行研究。

最后，在多节点系统上，我通常每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