我正在开发一个POS应用程序，它在每台POS计算机上都有一个本地数据库，并使用IIS中托管的WCF与服务器通信。该应用程序已在多个客户中部署了一年多。
大约一周前，我们已经开始从我们的一位客户那里获得IIS托管服务器的报告非常慢。当我检查了这个问题时，我看到应用程序池和我的进程火箭在8个cpu服务器上几乎100％的cpu。
我已经检查了SQL活动监视器和网络卷，并且它们没有显示超出我们通常看到的重大过载。
在Process Explorer中检查线程时，我看到很多线程反复调用CreateApplicationContext。我已经尝试安装.Net 2.0 SP1，根据我在网上发现的一些帖子，但它没有解决问题并用CLRCreateManagedInstance替换了函数调用。
我准备使用IIS进程的adplus和windbg来捕获转储，并试图弄清楚是什么问题。
有没有人遇到这样的事情，或者知道我应该检查哪个目录？
P.S。该应用程序的相同版本部署在另一个客户中，并且它可以正常工作。我也试过回滚版本（甚至是非常旧的版本），它的行为仍然完全一样。
编辑：好了，问题解决了，结果我在那里有一个没有限制结果集的SQL查询，当客户超过一定数量的行时，它开始陷入服务器的困境。我花了两天时间找到它，因为日志周围的所有噪音，但我等了一晚，然后转了一下，立刻向我展示了查询。
答案 0 :(得分：2)
通常这与硬件无关，而且与IIS的配置方式以及一些稍长时间运行的查询（100+毫秒）有关。
在您的应用程序池配置下，将您的Web园设置设置为20或更多。
Web园设置几乎是可用于处理应用程序请求的线程数。如果将其设置为1，那么单个查询可能会阻止处理其他请求，直到完成为止。
我有一个应用程序，每天处理近350万个请求。当Web园设置为1时，Web服务器CPU保持在100％并且有大量请求被丢弃。当我将其增加到50时，Web服务器CPU降至略低于2％并且没有请求被删除。
答案 1 :(得分：2)
我们遇到了同样的问题。某些IIS应用程序池进程的CPU使用率非常高，Web服务器上的CPU使用率约为100％。
首先，我们使用DebugDiag和ProcMon来缩小问题范围。见这里：http://www.iis.net/learn/troubleshoot/performance-issues/troubleshooting-high-cpu-in-an-iis-7x-application-pool
我们在DebugDiag分析中发现许多“此线程在WaitOne中等待”消息。这表明这些请求是为了一些reasong等待彼此。所以我们开始寻找共享的资源。我们唯一能找到的就是数据库。因此，我们认为尽管Web服务器具有100％的CPU使用率，但真正的问题需要是数据库服务器。
我的同事进一步调查此案。他做了以下事情：
1。）配置SQL Server的并行性
在数据库服务器上使用ProcMon，他发现SQL Server使用了太多的锁和锁存器。看看这里：http://blog.sqlauthority.com/2011/02/06/sql-server-cxpacket-parallelism-usual-solution-wait-type-day-6-of-28/
他将每个查询使用的处理器数量设置为4.默认值为0（我怀疑它等于可用的处理器数量 - 在我们的例子中为24）。您可以使用SQL Management Studio设置此项，方法是右键单击服务器节点本身并选择属性。
这对减少锁存器和加快请求产生了巨大的影响。我们的猜测是SQL Server过度使用了查询的并行化，导致在完成查询时过于繁重的同步。
2。）在数据库中创建新索引和缺失索引
我们在我们的网站上运行了第三方论坛软件，结果证明其数据库中根本没有使用任何索引。我的同事利用这里的知识：http://www.mssqltips.com/sqlservertip/1634/using-sql-server-dmvs-to-identify-missing-indexes/来创建几个新的索引。
现在案件似乎已经解决了。
答案 2 :(得分：1)
完全依靠直觉并做一个完整的猜测，听起来可能会发生异常，异常是被global.asax中的全局异常处理程序捕获，异常处理程序也导致抛出异常并倾销这个过程。也可能是由于病毒扫描实用程序锁定了一些文件。不过，我可能会 WAY 。
答案 3 :(得分：0)
不会消除硬件问题的可能性。我的服务器运行缓慢，发现它是主板问题。它在保修期内更换。