标签: cpu

我有一个带有被动节点和主动节点的 SQL Server 2008 R2 故障转移群集。服务器在物理上是相同的。我有两个 SQL Server 实例，一个设置为使用前 3 个 NUMA 节点中的所有 CPU，另一个设置为使用第 4 个 NUMA 节点中的所有 CPU。

这似乎工作正常，即使发生故障转移，但这是一个坏主意吗？

如果无源服务器没有那么多处理器，故障转移会发生什么？

您认为就虚拟来宾套接字/CPU 配置而言，实现最佳 SQL Server 性能的最佳配置是什么？我读过很多文章，指出宽插槽配置（每个插槽 1 个 cpu）可提供最佳性能。在其他文章中，SQL Server 的最佳性能是通过 1 个插槽和该插槽中的“x”个 cpu 来实现的。将来宾 VM 套接字/CPU 与物理主机配置相匹配。

SQL Server Standard 仅限于 4 个套接字，但您发现哪种配置性能最佳？我们计划在不久的将来进行负载测试。我期待您的反馈。提前致谢！！！

上周其中一个 SQL Server 出现问题，CPU 开始消耗超过 80%（正常为 10-30%）
这持续了大约 2 小时，直到我手动故障转移到 AG 中的辅助副本（这已经解决了问题）

问题开始：12:15
问题结束：14:15（手动 AG 故障转移后）

服务器信息：

SQL Server 2017  
32 logical processors (max DOP = 8)  
256 GB RAM (Max Server Memory = 180 GB, used 179 GB)

以下指标在问题出现之前与问题开始后没有明显变化

• 用户连接数/秒（平均 200-300）
• 批处理请求数/秒（平均 200 及更低）
• 数据库缓存内存 ( ~ 150 GB )

以下指标显着达到峰值，这对于该服务器来说并不典型（通常这些指标很低）：

• CPU（超过 80%）
• 内存授予待处理
• 锁定等待/秒，平均 锁等待时间，死锁
• 锁存等待时间
• 授予的工作区内存和保留的服务器内存

查询：

当问题开始时，我没有注意到此服务器的工作负载发生变化
开发人员还确认应用程序完成了他们通常的工作并正在运行常规查询，应用程序负载没有峰值

在这个“高 CPU 使用率”问题中，CPU 的前 10 个查询看起来并不异常
即使 CPU 正常（10-30 %），我们通常也会看到前 10 条查询

问题：

问题似乎出在几个相关的存储过程中，该应用程序通常每秒运行 1-4 次，而那些通常在 50 毫秒内完成，但在问题期间，只要我检查了 …

我只是在浏览系统运行状况扩展事件时遇到一个事件，其中包含用于显示工作线程状态的查询处理的诊断结果：

1. 当我有 80 个逻辑处理器时，为什么最大工作线程显示 2994，根据 msdn 计算，这里 512 + ((logical CPU's - 4) * 16)看起来不正确。但是，这里的最新链接对于大于 64 的逻辑处理器是有意义的，其中 16 的计算更改为 32。但是该链接说从 SQL 2017 开始，但是我得到的数字 2994 是针对 SQL2012, 14 16 的，其中逻辑处理器数为 80 . 我在这里遗漏了什么吗？

sp_configure 中的 max worker 设置设置为“0”

2. 回到该系统运行状况事件状态，显示以下 no 的警告：

maxWorkers="2944" workersCreated="456" workersIdle="314" tasksCompletedWithinInterval="1021881" pendingTasks="1"

我应该检查其他东西还是可以忽略它？

我使用 64 位操作系统和两个 CPU（每个 CPU 有 7 个逻辑处理器），逻辑处理器总数等于 14。

当我运行此代码时，我得到2048

SELECT max_workers_count FROM sys.dm_os_sys_info

另一方面，当我使用下面的公式时，我得到了完全不同的数字，即672

For a 64-bit operating system:
Total available logical CPUs <= 4
Max Worker Threads = 512
Total available logical CPUs > 4
Max Worker Threads = 512 + ((logical CPUs - 4)*16)

你能向我解释为什么我得到不同的数字吗？我在另一台服务器上对其进行了测试，两种情况的数字都完全相同。

编辑

PS 感谢 Dan Guzman 建议检查最大工作线程的服务器设置。这就是 EXEC sp_configure 'max worker threads' 返回的内容：

我最近注意到 SQL Server 错误日志中的一条错误消息显示“查询处理器耗尽了内部资源，无法生成查询计划”。我怀疑我的服务器可能内存或 CPU 资源不足。但是，我不确定如何确认这一点。

我知道 sysprocesses 和 sp_whoisactive 命令，但我不确定它们是否可以告诉我我的服务器目前是否耗尽了资源。

有人可以为我提供一些关于如何检查我的 SQL Server 当前是否内存或 CPU 资源不足的指导吗？任何帮助，将不胜感激。

默认情况下，SQL Server 允许最大并发连接数为 32767，这是可以同时登录 SQL Server 实例的最大用户数。

我正在开发 10 个 Web api，它们将使用自己的登录名查询 sql 服务器（因此最多 10 个登录名，加上管理员/开发人员）。预计并发登录数不超过20。

然而，每个登录 (api) 可以发出多个（也许 500 个）并发查询请求。因此，实际上 10 个 api * 500 个请求 = 5000 个并发查询请求。有时请求会较少或没有。

假设有足够的内存和磁盘 io 能力，我正在规划 cpu 要求。

据我所知，sql 请求被分配给工作线程，并且根据处理器的数量，有一定数量的默认工作线程。目前我的开发机器有 24 个处理器，因此默认的最大工作线程是 832。

假设查询可能超出线程占用成本（40），这意味着 SQL Server 可能决定使用并行性（最大 dop）。

假设 MAX DOP = 1，则一次可以处理 832 个请求。

假设 MAX DOP = 4，则一次可以处理 208 个请求。

超出此范围的任何查询请求都必须等待，直到为其分配工作线程。

那么，为了确保能够满足 5000 个请求的峰值负载，估计我至少需要大约 145 个 cpu 是否正确？

((145-4)*32)+512 = 5024

一些查询对我的 CPU 的影响非常严重。sp_WhoIsActive报告这sp_OAMethod就是原因（该sql_text列指向它）并且它具有PREEMPTIVE_OS_GETPROCADDRESS等待类型的巨大等待。鉴于这sp_OAMethod是一个内置存储过程，我该如何调试它？

我使用的是 2019 版本的 SQL Server，15.0.something。