我被要求在我们的生产服务器上为额外的500个用户进行负载testing。 为了这个目的，我使用了一个开源的应用程序; hammerora（ http://hammerora.sourceforge.net/ ），工作得很好。 我们的系统规格如下给出
**操作系统：Windows 2008 R2的Ent X64
CPU：内部x64（4物理* 6核心）NUMA
服务器内存：128 GB
SQL：2008 r2 std 64
没有：例如：2
每个实例的内存分配（64 GB（主），50GB）
连线数：1500-2250（主例）**
sp_configure'max worker threads'结果如下所示
名称：最大工作线程数
最低：128
最大32767
config_value：0
run_value：0
我们的主要生产分贝是在实例1（与64GB内存）。 对于负载testing目的，hammerora应用程序的数据库安装在主实例上，hammerora应用程序的数据和日志文件位于我们的生产数据库数据文件所在的驱动器上。
从perfmon跟踪我已经确定我们的生产数据库上的交易数量是（Databases（xxx）\ Transactions / sec）
最大666.0089
分钟4.999489
平均52.7313
StdDev 102.1578
对于负载testing的目的，我假设用户会发射156 /秒（avg tran + stddev trav值）当我今天进行负载testing时，服务器变得没有响应，当时的连接数是2655.在Perfmon跟踪I找不到任何可疑的东西。 处理器利用率不超过55％。 处理器队列长度大部分时间是0，但其中的一个点上升到了12，就是这样。
但在错误，我可以看到以下味精
分配给节点3上的进程的新查询在最近300秒内没有被工作线程拾取。 阻塞或长时间运行的查询可能会导致此情况，并可能降低客户端响应时间。 使用“最大工作线程”configuration选项来增加可允许线程的数量，或者优化当前正在运行的查询。 SQL进程利用率：6％。 系统空闲：92％。
服务器无响应的原因是什么？ 我如何解决它
VT
从错误消息，这听起来像你正在用完工作线程。
可用的工作线程数取决于您的硬件。 你可以在这里看到具体细节。
在（很多）其他事情中，工作线程处理查询。 当应用程序向服务器发送一个查询时，SQLselect一个空闲的工作线程并给它查询处理。 查询完成后，结果返回到应用程序，工作线程再次变为空闲状态。 如果没有空闲的工作线程，查询就会排队并等待。 如果等待时间过长，则查询不计划，应用程序将收到错误。 （这是没有细节的，超级光面的解释。）当SQL Server用完工作线程时，它可能陷入奇怪和令人沮丧的方式。 通常情况下，您将无法login。
你可以增加工作线程的数量（它仍然需要重启，IIRC）， 但是微软说你不应该那样做。 几年前，我真的让他们抱怨我这样做，这就是为什么你的post引起我的注意。
回到关键点：基本上，对于服务器上的负载量，服务器对于工作线程来说是非常困难的。 有可能已经很繁忙的驱动器上的数据文件出现任何缓慢，这可能会加剧。
我不熟悉hammerora。 hammerora是否使用从您的“真实”生产应用程序捕获的stream量，还是由它自己组成？
“交易”是一个有趣的术语。 每个应用程序对事务进行了不同的概念，但是perfmon只报告一个非常粗糙的数字。 考虑一下：员工表中的一条loggingselect和百万行表的更新都被视为“一个事务”，但是对于服务器来说，这是一个非常不同的工作量。
为什么hammerora有自己的数据库？ 运行testing？ 还是数据库只是用来存储结果？ 如果hammerora正在testing它自己的数据库，你真的testing你的服务器扩展hammerora的能力，而不是你的“真正的”生产应用程序，它可能会有不同的performance。
此外，从perfmon trace中看到的数字将包含许多轻量级查询，这些查询符合事务处理的要求，但不会对服务器造成重大负担。 （sp_reset_connection就是一个很好的例子，它被调用了很多，但是没有太多的负载，你可能会每秒运行几千个）。所以，如果生产服务器每秒运行156个事务，并且大部分是轻量级，然后hammerora去运行每秒156重的交易，这是一个问题。
如果我负载testing服务器，我会从小开始，然后调整起来。 换句话说，不要从156开始，从15开始。观察服务器如何执行perfmon。 完成后，加载两次，然后重试。 这是如何解决的？ 然后，加倍负载，然后再试一次。 冲洗。 重复。 等等。最终服务器将开始行为不端。 那就是当你说“这就是这个服务器可以做的事情”，并且，如果有必要的话，开始寻找方法来优化查询或改进服务器。
哦，我不确定我会在生产服务器上进行负载testing。 这肯定会在某个时候停滞不前，而用户也不会这样。
达林是对的：
a）从一个小的负荷开始，build立起来
并且
b）设置一个频繁起火的locking/locking监视器，并logging到一个表格（在另一个主轴上）。 寻找块/锁….优化，重复…