有人使用 SUMA、跟踪标志 8048 或跟踪标志 8015 吗？

Question

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

有兴趣听取其他人的意见，他们发现性能值由跟踪标志 8048（将查询内存授予策略从每个 NUMA 节点提升到每个核心）、跟踪标志 8015（SQL Server 忽略物理 NUMA）或 SUMA（交错足够统一的内存访问，某些 NUMA 机器上的 BIOS 选项）。

跟踪标志 8048

跟踪标志 8015

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

跟踪标志 8048 是一个“修复”，但它是最好的修复吗？SQL Server 是否会因为跟踪标志 8015 而忽略物理 NUMA 已经完成了同样的事情？如何将 BIOS 设置为交错内存，让服务器使用 SMP 模拟 SUMA 行为而不是 NUMA 行为？

关于系统

• 4 六核 Xeon E7540 @ 2.00GHz，超线程
• 128 GB 内存
• WS2008R2
• MSSQL 2008 R2 SP2
• 最大值 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 节点。

干预

MSSQL 已在 -T8048 到位的情况下重新启动。差异立即显现：缓冲区页面查找率上升超过 100 万次，并飙升至每秒 800 万次。以前无法在 24 小时内完成的问题批处理工作负载，在不到 4 小时内完成。作为验证跟踪标志 8048 的校正值的一部分（并确保其不需要的副作用最小），提交了另一个不是调查或干预重点的批处理工作负载。该报告批次以前在 2 小时内完成；跟踪标志 8048 到位后，报告批次在大约 20 分钟内完成。

Nightly ETL 也遇到了一个好处。ETL 时间从大约 60 分钟下降到 40 分钟。

综合几个地方的信息，我推测报告队列的高度，并发报告计数大于硬件线程计数，所有报告的单用户帐户加在一起给一个NUMA节点造成压力，直到工作线程压力导致它对同一用户帐户的下一个传入连接请求不利，此时下一个 NUMA 节点将立即获得一定数量的连接。每个 NUMA 节点最终都会很可能会导致查询内存授予瓶颈。

为查询内存授予打开更多通道消除了瓶颈。但是，我不确定成本。Bob Dorr 的 CSS 帖子明确指出跟踪标志 8048 存在额外的内存开销。该开销是否在由 MSSQL 2008 R2 最大服务器内存管理的单页分配器区域内？如果是这样，我猜系统只会在缓冲池缓存中少一些数据库页面。如果没有，是否应该降低最大服务器内存以适应？

Answer 1

这是一个很棒的帖子。

为了回答您的最后一个问题，我推测您的回答是“是”。

也就是说，在诉诸跟踪标志之前，我可能会追求软 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