症状：
下班前，收到报警邮件。一个应用的两台服务器CPU 过高。打开监控一看CPU都100了。没找到原因之前，先抓好DUMP 然后重启应用程序池。
!threadpool 可以看到CPU 利用率
!runaway 查看运行的线程和运行时间
解决CPU 高的问题，应该从运行的线程上分析。分析它们都在干什么，哪个线程一直占用CPU运行时间
~threadid s 切换到运行时间最长的几个线程
k 显示当前线程的call stack
发现都是在GC线程（SVR::gc_heap::gc_thread_stub） ，难道是它们造成了CPU 高？
但已经运行了十几个小时，CPU是突然升高的。应该不是这几个线程的问题。
然后，我把所有线程都切换一下，查看线程的调用堆栈
发现很多线程都是再等待GC 完成（SVR::GCHeap::WaitUntilGCComplete）
应该是某个线程，正在触发GC函数——从网上找到的方法。
~* kb 得到所有的本地调用堆栈寻找线程中触发GC的函数
（mscorwks!SVR::GCHeap::GarbageCollectGeneration）
搜索后找到是102这个线程正在触发GC，调用System.String.InternalSubString(Int32, Int32, Boolean) 字符串截取的时候。需要收集大对象（clr!SVR::gc_heap::allocate_large_object，clr!SVR::gc_heap::allocate_more_space），分配更多的空间。显然因为字符串很大才会造成GC大对象。
!dumpstackobjects 打印当前线程保存的托管对象。
通过这个找到一些线索。如下图
这是根据国家查找的请求，将会返回很大的数据量。序列化将产生很大的字符串。
再查找代码，返回结果前会执行return xml.TrimEnd(‘\0‘); 难怪会调用InternalSubString 字符串截取的方法。这会第二次分配一个很大的空间来存储转换后的字符串。
另外查找其它线程后发现有八个线程都在调用同一个方法：
!clrstack –p 查看参数地址
!do 0x0000000120ec8fc8 查看对象
都是同样的请求，这样将造成频繁的GC，导致CPU 升高。
最后通过查看监控发现，这个接口的调用量有突然上升和CPU 升高的时间点是一致的。联系调用方确认下原因，他们的memcached 那段时间失效，造成每次都直接调用接口拉取数据。服务器的负载均衡不完美，大量请求都映射到同两台机器上，使得两台机器CPU 一百。