我们正在使用 NUMA 架构服务器的 64 位 12 核、2 插槽服务器上运行 SQL Server 2012 SP1 CU4。操作系统是 Windows Server 2008 R2 x64。
每当我们将超过 50% 的物理 RAM 分配给 SQL 服务器时，机器就会变得不稳定或无响应。
这些症状是操作系统内存不足的典型症状——即进程无法启动、GUI 对象无法呈现、应用程序行为异常、远程桌面会话无响应等。
我们已经在两台不同的机器上看到了这种情况——一台有 192GB 的 RAM，另一台有 256GB 的 RAM……只要 SQL 被分配到各自物理总量的 50% 以上，症状就会出现。
有没有其他人看到过这种行为？
- - 编辑 - -
SQL 服务在具有 LPIM（内存中的锁定页面）权限的帐户下运行。
遗憾的是，McAfee 防病毒软件是强加在服务器上的，尽管它至少为所有 SQL 文件设置了排除项。
当 RAM 利用率允许超过 50% 时，我们看到的常见行为是：
-- 编辑 2 ---
我们已经尝试重新安装 SQL (SP1 CU4)，并检查过没有其他东西占用 RAM。通常，在任何时候，总 256GB 中至少有 100GB 可用。当我们关闭 LPIM 时，我们会看到“操作系统已在 SQL 内存的重要部分进行交换”的问题，这就是我们将其打开的原因。
小智 5
我会检查 per-cpu CPU 忙的 perfmon 指标，以及 PLE、数据库页面等的实例范围和每个 NUMA 节点的 perfmon 指标。 两个最近的 SQL Server KB
但是，对于某些工作负载，尤其是具有更高内核数、高并发查询数和大量数据库磁盘 IO 的工作负载，使用跟踪标志 8015（在 SQL Server 级别禁用 NUMA 支持）和 8048（删除每套接字查询内存分配瓶颈）将提供比 SQL Server 2012 SP1 CU4 中包含的修复更好的结果。（我在我们的测试设备上通过我们的工作负载模拟证实了这一点 - YMMV）
跟踪标志 8015 值得在部署前进行彻底评估。为了管理单个大型 bpool，牺牲了内存亲和性和降低内存延迟。它还导致一个惰性写入器而不是每个 NUMA 节点一个，并且将单个 SQL Server 实例中的连接端点关联到每个 NUMA 节点的想法也消失了。但对于某些工作负载而言，其好处是不可否认的。不要在没有 8048 的情况下使用 8015。
我从未见过或听说过添加跟踪标志 8048 的任何可衡量的成本，如果CMEMTHREAD等待和关联的自旋锁是由查询内存分配触发的 - 这是消除它们的唯一可靠方法。