Debug和Perfmon里的一些特殊值

1. 通过! FinalizeQueue检查是否有大量的SqlConnection对象等待被Finalize. 通常Finalize queue中的Connection应该为0，或者小于10。当数量超过30的时候，通常说明代码中有使用完SqlConnection后忘记及时调用 Close或者Dispose的情况。
2. 通过!dumpheap –stat检查内存中是否有大量的DataTable对象。如果有，通过!gcroot察看这些对象是否被保存到Session中。在Session中保存大量的数据容易导致很高的内存压力。
3. 超过30个CLR线程表明程序中往往有blocking发生。
4. % Processor Time ：程序繁忙时，CPU平均占用率应该在80%以内，否则应该去检查high cpu的情况。其次是波动很大，在短时间内有连续较高值出现。
5. ID Process：如果iis做了recycle或者asp.net程序crash了，可以看到这个值的变化
6. Private Bytes：如果值在一直升高，memory leak。这个值跟taskmgr里的vm是差不多的。
7. Virtual Bytes：一般与Privates Bytes成正比，比其略大。当>2倍大小的Private Bytes时，一般是fragment的问题
8. Context Switch/sec：如果high cpu跟该值变化一致，一般就不是死循环了，是contention的问题。线程切换开销比较大。
9. Bytes in all heaps：GC回收不了的所有object占用的总空间，只有GC在collect的时候这个值才会变化。
10. %Time in GC：GC执行的频度，一般<15%，大于>20%的时候对性能会产生影响。如果负载高，内存压力大都有可能导致该值高
11. Application Restarts：记录asp.net app domain重启次数。重启一般是因为bin目录下有文件改动或者web.config被改动。
12. Request Execution Time：注意的是要看平均值，峰值一般不能说明什么（GC）
13. Request Current：正在处理和等待处理请求数。>10时要看一下了，如果此时cpu不高，出现blocking的可能性最大。
14. Request Executing：这个值应该跟cpu数一样（这个cpu数是值taskmgr里看到的cpu数，比如超线程的cpu这个值一般是2）
15. Requests/sec：每秒处理请求数，几乎是衡量asp.net负载的标准。如果该值有较大波动，应该考虑Ddos的可能性。
16. Request in Application Queue：该值如果>0，说明性能问题非常严重。当该值达到一定程度的时候，asp.net直接返回503。
17. .NET CLR Exceptions下的# of Excepts Thrown / sec：该值如果超过20，一般就有不正常的地方。这里的exceptions包括了已经catch到的。exception是影响性能的。 asp.net中的Response.End()方法调用也会有一个异常的。