每个人都有这种经历，我们N多人辛苦作出来的软件，放到客户那里，过了一段时间，随着业务数据的增加和在线用户的增加，就开始“衰老”了。症状，典型的有几种：
1. 内存由100M疯涨到了1700M，最终要频繁重启进程或者服务器。
2. CPU狂涨到了100%，你用taskmgr眼睁睁的看着你的某个w3wp.exe站在那里居高不下。
3. 你的Button点下去之后，服务器内存很平稳，CPU一直低于5%，但是你的程序就是没有响应。
4. 客户无意中发现，event logs里面有大量的诸如aspnet_wp被recycled、某个dllhost突然访问了某个不该访问的地址。
5. ==………………………………
当我们还是少年的时候，碰到这种事情，第一件事就是问候BillG的所有女性亲属，然后手足无措的低头挨训 - 老板的抑或客户的。
这些问题，从良心上讲，基本上和BillG没关系，99.9999%的可能性，和我们自己相关。对于这种问题，我们需要的是解决思路。而解决问题的通则之一，就是对现象就行分类（能否看到本质，还说不上，呵呵）。对于上面的4种情况，我们一般归纳为几种情况：
l Memory Leak，就是内存泄漏
l Hang，某个东西挂起了
l Access Violation，访问了你不该访问的东西
那么，第一个疑问，如何把上面的N个问题，对号到这三种情况？
答案是，工具！每台Windows Server上，都有下面这几个工具：task manager、performance monitor、Event Viewer，对应的命令行分别是：taskmgr、perfmon、eventvwr。
对于上面的问题1，我们可以先用taskmgr找出有问题的进程，然后restart该进程。然后打开perfmon，建立一个log，抓取的对象是：Process。等内存涨到你忍受不了的地步的时候，stop那个log。
OK！我们再次打开perfmon，打开刚才那个log（它的尺寸应该和你的虚拟内存+物理内存大小相当），添加Process里面我们自己的那个进程，添加Private Bytes这个计数器。如果我们发现，这个值一直增长，直到最后，也没有掉下来，那么就基本可以确认为是Memory Leak的问题。
对于Performance Monitor，里面的Process/Processor/Memory/Physical Disks/Networks/System，都是我们经常要观察的。具体的含义，可以看perfmon自己的帮助。
对于上面的问题2，用taskmgr也能判断，但是taskmgr的缺点是，它是实时的，我们看不到CPU的趋势。所以，用perfmon我们可以检测Process，分析里面的几个cpu计数器。
问题3，稍微棘手一些，通过taskmgr或者performance monitor，看到的CPU和内存都很低。解决办法，后面再说。
问题4，系统的事件察看器中，有一些Dllhost发生Crash的记录，也有一些aspnet_wp被回收的记录。对于前者，我们叫做Crash，这可能是Access Violation引起的；对于后者，大部分情况是Memory Leak，或者某个杀毒软件干的事。
通过几个系统自带的工具，我们能够把客户眼中的问题，归纳到我们画的圈子中，下一步，就是要通过另外的手段，来解决它了。
（待续）