sql服务器并发性能

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

我们发现，当活动会话数增加到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. PS：我们测试了没有并发请求的情况下，一个事务（可读写5个表）在应用程序级别大约需要1秒，因此2个CPU是否可以很好地处理25个活动会话（500个活动事务）。

2. PS：被阻止的事务主要是由于2个表上的锁引起的。

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

您可以选择对所有事物都在爬行时的情况进行全面了解：

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

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

您的问题很可能是由于

• 设计不良
• 索引编制不良

锁定/阻塞是由于索引时间不佳而导致的，因为所有时间都花费在端对端扫描表上。CPU在这里无关紧要。

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

我同意GBN和玛丽安（Marian）的观点。

要回答有关2-CPU处理25个请求的问题：我有一个2-CPU系统，它支持大约750个用户连接，并且平均每秒运行4K Batch Requests。对我来说，以下几项很重要：设计，管理和调整。如果您的应用程序和数据库设计不佳，那么负载将失败（请考虑扩展）。

高CPU可能表明内存压力。您提到只有7GB的内存可用于SQL Server。如果索引执行不佳（索引过多，索引错误或没有索引），则这将导致系统在有适当索引的情况下将数据库的更多页面分页到内存中以应对各种请求。我会警告说，疯狂地创建索引是因为错误的索引也会对您造成伤害，因为每个索引都有可能在行更新（Create-Update-Delete）操作过程中需要更新。

同样，使用丢失索引DMV要求使用对应用程序和数据库的了解，而不仅仅是实现每个建议的索引。我会在此处查看 Kimberly Tripp关于索引的博客条目。在“索引”部分之后，查看其他类别可能会对您有所帮助。

如果您在单个事务中对5个表的Java / Hibernate更新正在通过多次往返数据库进行更新，那么您将面临争用（CRUD阻塞请求）。如果应用程序无法及时返回数据库，则问题将进一步恶化。在应用程序中时，关联的活动事务可能会阻止其他请求的处理并导致请求超时。

将以上两个问题加在一起，您就会遇到讨厌的性能问题。

减少单个事务内的数据库往返次数将是一件非常好的事情。也许存储过程会有所帮助。

其余的将需要工作才能使您的应用程序扩展。您可能还考虑了内存，但这应该在设计和性能审查完成之后进行，并且由于立即添加内存而实施的必要更改将掩盖您的问题。

绝对遵循玛丽安（Marian）提出的建议。

我想说您发现自己是一个很棒的挑战，并祝您成功！

1. 以我的经验，我们有带2个cpu的MS SQL Server 2000和30多个活动会话以及1000多个事务。服务器虽然很难，但是却有效。
2. 我不确定锁是否使用更多的CPU。我认为锁和CPU使用率是两个不同的性能问题。

对于解决方案，首先应确保您的主要问题是CPU。尝试阅读此问题以查找问题的根源并获取适当的解决方案。最好，如果您可以使交易尽可能小-做到这一点。

我的第一个想法是减少事务数量并减少阻塞量。您可以将某些交易分成多个部分吗？您可以从事务中提取一些查询吗？正如Alex_1提到的，在这里最小的交易是理想的。

我同意gbn，添加索引也可能会有所帮助。

另一个想法是，我也将看看您的锁。仅更新一行时，是否要删除表级锁？您可能会考虑建议对SQL Server进行行级锁定。那会解决很多问题。（当然，如果您有5张桌子，可能不是这种情况，只是一个想法。）

最后，我来看看您正在使用的表。如果每个人都在一个特定的表上阻塞，您可以将该表的逻辑移到事务结束吗？如果您可以减少对该高需求表进行锁定的时间，则可能会有所帮助。