主页 / dba / 问题 / 241902
Accepted
SqlWorldWide
Asked: 2019-07-03 07:29:02 +0800 CST

Thread Count is too high-我可以在短期内做什么？

  • 772

在我发布这个问题之前，请阅读以下文章。

我熟悉通过查看以下项目（不全面）来调查高线程数问题：

  • Maxdop 设置
  • 并行度设置的成本阈值
  • CPU压力
  • 工作队列长度
  • 执行计划

在我决定做出改变之前，这项调查可能需要几个小时。我可以在短期内做什么，这样请求就不会等待分配工作线程？

我们使用 SCOM 来监控 SQL Server 的许多方面，这就是其中之一。我知道这更多是信息性消息，但始终来自同一服务器的查看使我们有机会查看我上面列出的内容。我想从社区中找出什么，如果他们采取某些行动（可能是暂时的，直到完成全面评估），work_queue_count一旦 SCOM 触发警报，是否持续大于零。有时很容易检测到消耗大量线程但并非总是如此的单个查询。

sql-server cpu

1 个回答

  1. Best Answer

    [max workers] 的默认公式（等于或低于 64 个逻辑 CPU）：16*（逻辑 CPU - 4）+ 512

    如果您想提高 [max workers]，这里有两个潜在的理由。如果由于保留的工作人员数量而发生 DOP 降级时 CPU 未饱和，则负面后果是有限的。YMMV。

    1. 一般：在 sql server 2019 中（可能之前？我没有检查过）如果超过 64 个逻辑 cpu/用户调度程序，默认乘数从 16 更改为 32。对于我关心的系统，每个调度程序的预期工作强度是8 vcpu 或 80 都一样。那么为什么不总是使用 32 呢？
    2. 特定于定位 re：超线程。同样，对于我的工作负载，无论是否使用 HT ，每个内核的预期工作强度都是相同的。但是虚拟机每个 pcpu 有 1 个 vcpu。有些物理服务器禁用了 HT。在这些情况下，如果启用了 HT，为什么不使用系统的“理论”逻辑 CPU/调度程序计数？
    • 3

相关问题