sql server 并发性能

Question

我们在生产环境中遇到了一些性能问题。

我们发现，当活动会话数超过 25 时，CPU 使用率达到 100%，并且需要很长时间才能下降。

---

我们拥有的环境：

产品 Microsoft SQL Server 企业版 9.3(sp2)

CPU 2（至强 2.13）

内存7G

会话详细信息 1 的快照

活动会话 25

第 496 章

空闲会话 289

被阻止的交易29

会话详细信息 2 的快照

活动会话 59

活跃交易 885

第 267 章

被阻止的交易49

---

我想知道：

1. 2CPU 是否可以处理25 个活动会话（500 个活动事务）。 PS：我们测试过，没有并发请求，一个事务，读/写5 个表，在应用程序级别大约需要1 秒。

2. 阻塞的事务是否占用更多的CPU。 PS：阻塞的事务主要是因为2个表上的锁。

解决方案是什么：添加 CPU 或调整应用程序（java/hibernate）以缩短此事务并减少表中的块？

Answer 1

当一切都在爬行时，您可以选择对情况有一个很好的了解：

• 使用服务器端跟踪查看最长和最重的会话
• 使用Adam Machanic的Who is Active存储过程 - 保存服务器加载时刻的信息 - 很棒的免费脚本
• 使用Management Studio 中的Activity Monitor只是为了获得直观的一瞥（Cpu 和 IO 是我发现最有用的那些）——Management Studio 中包含的非常好的工具
• 使用第 3 方免费工具 - Confio Ignite Free - 当一切都很缓慢并且需要查看有关等待统计信息、阻塞等的详细信息时，这非常有用。- 很棒的免费工具
• 检查统计数据是否是最新的
• 检查索引是否碎片化，如果是，则对其进行碎片整理
• 遵循检查缺失索引的其他建议，设计
• 检查在您的数据库中使用快照隔离级别的可能性（您有很高的阻塞，因此很高兴查看您是否真的需要当前的隔离级别）

祝你调查问题好运:-)。

Answer 2

您的问题很可能是由以下原因引起的查询性能不佳

• 糟糕的设计
• 索引不好

锁/阻塞来自糟糕的索引，因为所有时间都花费在端到端扫描表上。CPU在这里无关紧要。

作为快速修复，请使用本文中的信息检查缺失的索引：http : //blogs.msdn.com/b/bartd/archive/2007/07/19/are-you-using-sql-s-missing-索引-dmvs.aspx

Answer 3

1. 根据我的经验，我们拥有带有 2 个 CPU 的 MS SQL Server 2000，以及超过 30 个活动会话和超过 1000 个事务。服务起来很困难，但它确实有效。
2. 我不确定锁会使用更多的CPU。在我看来，锁和 CPU 使用率是两个不同的性能问题。

至于解决方案，首先你应该确定你的主要问题是CPU。尝试阅读本期以找到问题的根源并获得适当的解决方案。最后，如果你可以让你的交易尽可能小——那就去做吧。