高CPU、数据库无法读写

高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的销毁方式是不是不够直接彻底。

这里读的连接没有销毁，印证了上述推断，再让他们检查一下该服务中有没有正确使用该仓储即可。