不响应的 SQL 服务器

Question 1

从错误信息来看，听起来好像您的工作线程已经用完了。

可用的工作线程数取决于您的硬件。您可以查看具体信息这里。

除了（很多）其他事情之外，工作线程还处理查询。当应用程序向服务器发送查询时，SQL 会选择一个空闲的工作线程并让其处理查询。查询完成并将结果返回到应用程序后，工作线程再次变为空闲状态。如果没有空闲的工作线程，查询将排队并等待。如果等待时间过长，查询将无法安排，应用程序将收到错误。（这是没有细节、非常华丽的解释。）当 SQL Server 用完工作线程时，它会以奇怪和令人沮丧的方式陷入困境。通常，您将无法登录。

你能增加工作线程的数量（据我回忆，它仍然需要重新启动），但微软说你不应该这么做。很多年前，他们确实因为我这么做而抱怨过我，这就是为什么你的帖子引起了我的注意。

回到正题：基本上，对于您向服务器施加的负载量，服务器缺少工作线程。如果数据文件位于可能已经很忙的驱动器上，则会导致速度缓慢，从而加剧这种情况。

我对 hammerora 不太熟悉。hammerora 是否使用从您的“真实”生产应用程序捕获的流量，还是它自己生成的流量？

“事务”是一个有趣的术语。每个应用程序对于事务的内容都有不同的看法，但 perfmon 只报告一个非常粗略的数字。想想看：从员工表中选择一条记录和更新一百万行表都算作“一个事务”，但对于服务器来说，它们的工作量非常不同。

为什么 hammerora 有自己的数据库？用来运行测试吗？还是数据库只是用来存储结果？如果 hammerora 正在测试自己的数据库，那么您实际上是在测试服务器扩展 hammerora 的能力，而不是测试“真正的”生产应用程序，后者的行为可能会有所不同。

此外，您从 perfmon 跟踪中看到的数字将包括大量符合事务条件但不会对服务器施加重大负载的轻量级查询。（sp_reset_connection 就是一个很好的例子。它被调用了很多次，但负载并不大。您可能每秒可以运行数千个这样的查询。）因此，如果生产服务器每秒运行 156 个事务，其中大多数是轻量级的，然后 hammerora 每秒运行 156 个重度事务，那就有问题了。

如果我要对服务器进行负载测试，我会从小处着手，然后逐步加大。换句话说，不要从 156 开始，而是从 15 开始。使用 perfmon 观察服务器的性能。完成后，将负载加倍，然后重试。结果如何？然后，将负载加倍，然后重试。反复。等等。最终，服务器将开始出现问题。这时，您会说“这就是该服务器可以做的事情”，并且如果有必要，开始寻找优化查询或改进服务器的方法。

哦，我不确定我是否会在生产服务器上进行负载测试。它肯定会在某个时候陷入困境，而用户不会喜欢这样。

Answer