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最大服务器内存控制？如果是这样，我猜想系统在缓冲池缓存中将只少一些数据库页面。如果没有，应该降低最大服务器内存来容纳吗？