4.实际操作分享篇
    
  上面三个环节，任何一个发生问题，都会影响到系统的效率；我分享我们实际的作业的过程发生的一些情况，及怎么解决这些问题。

  （1）内存使用达到峰值，导致程序无法继续运行;

   有个同事分享了他们的经验如下（原话分享）：

  我们有一些程式是server跑的Job，并有越来越多之势。而大家在写程式的时候可能比较少考虑到耗内存这个问题。

  下面的例子也许会给我们一点启示。

  下面也是原话:

  Pls help to check the Run In Rack Job program .  It will no response after running two or three days . the AP server Memory usage will over 2.5G . after we close the the program , Memory will decrease to 1.5 .

  大致意思是：在服务器端(也叫后台)自动跑的一只程式，运行了两三天后，停止运行了；检查Server的内存使用率时,发现超过了2.5G;在关掉了这只程式后，它就降到了1.5G…下面的图片为证：

  （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.