高CPU、数据库无法读写的真凶
有兴趣的同学可以参考如下系列文章，都是针对dump分析的实战和总结：
Windbg DUMP分析（原创汇总）
http://www.cnblogs.com/LoveOfPrince/p/6653341.html
记一次内存泄漏DUMP分析
http://www.cnblogs.com/LoveOfPrince/p/6032523.html
-------------------------------------------------回归正题----------------------------------------------------------------------
前些天某个服务，线上CPU经常飙到很高，且其它服务间歇性的无法读写数据库。
攻城狮们查了几天，没有明显发现。
后来，他们抛了一个dump给我，初步分析只有该服务使用了公司内基于EF自建的仓储，问题应该在这里。
苦于没有该仓储的代码权限，且手上事情较多，就先让他们自己查下该仓储。
第二天顺手要了该仓储的代码，又抓了几个dump，基本敲定，细节如下：
1.托管线程堆栈大多停留在如下，且占用不少耗时。
DatabaseLogFormatter.Executing 000000000e6bbfb8 0000000077c2bd7a [HelperMethodFrame: 000000000e6bbfb8] 000000000e6bc100 000007fe99238fc0 System.Data.Entity.Infrastructure.Interception.DatabaseLogFormatter.Executing[[System.__Canon, mscorlib]](System.Data.Common.DbCommand, System.Data.Entity.Infrastructure.Interception.DbCommandInterceptionContext`1<System.__Canon>) 000000000e6bc160 000007fe99238ec6 System.Data.Entity.Infrastructure.Interception.DatabaseLogFormatter.ReaderExecuting(System.Data.Common.DbCommand
2.进一步分析，二代龄要回收的对象太多。
Heap 0 generation 0 has 35 finalizable objects (000000000f312ec0->000000000f312fd8) generation 1 has 4 finalizable objects (000000000f312ea0->000000000f312ec0) generation 2 has 48152 finalizable objects (000000000f2b4de0->000000000f312ea0) Ready for finalization 0 objects (000000000f312fd8->000000000f312fd8) ------------------------------ Heap 1 generation 0 has 12 finalizable objects (000000001165a780->000000001165a7e0) generation 1 has 3 finalizable objects (000000001165a768->000000001165a780) generation 2 has 49727 finalizable objects (00000000115f9570->000000001165a768) Ready for finalization 0 objects (000000001165a7e0->000000001165a7e0) ------------------------------ Heap 2 generation 0 has 19 finalizable objects (00000000115a4c30->00000000115a4cc8) generation 1 has 9 finalizable objects (00000000115a4be8->00000000115a4c30) generation 2 has 42725 finalizable objects (00000000115514c0->00000000115a4be8) Ready for finalization 0 objects (00000000115a4cc8->00000000115a4cc8) ------------------------------ Heap 3 generation 0 has 18 finalizable objects (000000000f36a9b8->000000000f36aa48) generation 1 has 14 finalizable objects (000000000f36a948->000000000f36a9b8) generation 2 has 44483 finalizable objects (000000000f313b30->000000000f36a948) Ready for finalization 0 objects (000000000f36aa48->000000000f36aa48)
且这些对象大都是EF相关的。
MT Count TotalSize Class Name 000007fef694bb40 3162 227664 System.Reflection.Emit.DynamicResolver 000007fef68e76d0 36109 866616 System.WeakReference 000007fe987e9f40 35941 4887976 System.Data.Entity.Core.EntityClient.EntityConnection 000007fe987d75f0 37157 5053352 MySql.Data.MySqlClient.MySqlConnection 000007fe987e7d58 35952 6615168 System.Data.Entity.Core.Objects.ObjectContext 000007fe98814690 35952 8053248 System.Data.Entity.Internal.LazyInternalContext
3.如上来看，疑点还是在仓储这块。
跟踪堆栈，来看MySqlConnection的话，考虑XDbContext : IDisposable的销毁方式是不是不够直接彻底。
这里读的连接没有销毁，印证了上述推断，再让他们检查一下该服务中有没有正确使用该仓储即可。