高CPU、數據庫沒法讀寫的真兇

有興趣的同窗能夠參考以下系列文章,都是針對dump分析的實戰和總結:html

Windbg DUMP分析(原創匯總) 數據庫

http://www.cnblogs.com/LoveOfPrince/p/6653341.htmlspa

 

記一次內存泄漏DUMP分析線程

http://www.cnblogs.com/LoveOfPrince/p/6032523.htmlcode

 

-------------------------------------------------迴歸正題----------------------------------------------------------------------orm

前些天某個服務,線上CPU常常飆到很高,且其它服務間歇性的沒法讀寫數據庫。htm

 

攻城獅們查了幾天,沒有明顯發現。對象

後來,他們拋了一個dump給我,初步分析只有該服務使用了公司內基於EF自建的倉儲,問題應該在這裏。blog

苦於沒有該倉儲的代碼權限,且手上事情較多,就先讓他們本身查下該倉儲。內存

 

次日順手要了該倉儲的代碼,又抓了幾個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的銷燬方式是否是不夠直接完全。

 

這裏讀的鏈接沒有銷燬,印證了上述推斷,再讓他們檢查一下該服務中有沒有正確使用該倉儲便可。

 

是否是有點成就感...我是否是應該先去找個妹子、結束單身才是正事啊😭

相關文章
相關標籤/搜索