4.2 进程请求过多，导致CPU无法及时处理，程序效率反应较慢。
下面都是同事的原话:
| “年后产量逐渐增加，新的问题又出现了。从Server Performance上分析，和上次Memory过高不同的是CPU使用率过高。 每当CPU过高的时候，产线会大面积的反应说慢（这点和连接到哪台AP有关系）。 每次慢的时候，我们就找到CPU过高的那台AP，recycle IIS的application pool后就OK了。 于是我么再次找到Bon帮忙分析（结论:微软结案报告 20090226V1 - SRT090119833891 Web service can't serve IISReset can fix.msg）。并给出了开发程序时的一些建议。 结论大致是说，没有进程占用了特别高的CPU，也没有进程占用CPU时间过长。只是对DB的请求的进程过多（比较吻合3厂的实际状况—附件多，刷的快），加起来就整体过高。 还发现了很多DLL是built in debug mode，这些DLL占用了过多的memory资源。 后来根据Bon的建议，我们修改了IIS application pool的设定如下，解决过多请求不能及时处理，而造成CPU过高的问题。” |
这里有一些问答关于应用连接池(Application Pool)的设定，对理解这样的设置有一定的帮助:
1. Is one application pool’s maximum memory usage 1.5G?
A&: Each application pool is a w3wp.exe. w3wp.exe is a process. Every process has 2 G User mode virtual address, so the maximum memory usage for application pool is 2G. However, you can’t make sure that there is no memory fragment issue. Therefore, Out of memory always occur after 1.5 G according to our experience.
2. Is each application pool independent on memory usage?
A&: Different application pools are different w3wp.exe, so each application pool’s maximum memory usage is 2G.
3. Can setup maximum CPU usage on each application pool?
A&: You can monitor it, but you can’t setup it.
写完这篇文章的时候，我们另一项目组的开发者，也遇到了同样的问题，他们开发好的一只程式，用户反映很慢。我跑过去一看代码，完了，所有我描述的问题，他们都无一避免地出现啦，那就赶紧告诉他们，还等什么？
