网站域名缴费十年,网站域名重定向,厦门u 网站建设,中国建筑劳务分包网一#xff1a;背景 1. 讲故事前几天有位朋友加wx说他的程序遭遇了内存暴涨#xff0c;求助如何分析#xff1f;和这位朋友聊下来#xff0c;这个dump也是取自一个HIS系统#xff0c;如朋友所说我这真的是和医院杠上了????????????#xff0c;这样也好#x… 一背景 1. 讲故事前几天有位朋友加wx说他的程序遭遇了内存暴涨求助如何分析和这位朋友聊下来这个dump也是取自一个HIS系统如朋友所说我这真的是和医院杠上了????????????这样也好给自己攒点资源????????????好了不扯了上windbg说话。二windbg 分析 1. 托管还是非托管既然是内存暴涨那就看看当前进程的 commit 内存有多大
0:000 !address -summary--- State Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal
MEM_FREE 174 7ffebaac0000 ( 127.995 TB) 100.00%
MEM_COMMIT 1153 133bd3000 ( 4.808 GB) 94.59% 0.00%
MEM_RESERVE 221 01195d000 ( 281.363 MB) 5.41% 0.00%可以看出大概占了 4.8G,接下来再看看托管堆内存。
0:000 !eeheap -gc
Number of GC Heaps: 1
generation 0 starts at 0x00000207a4fc48c8
generation 1 starts at 0x00000207a3dc3138
generation 2 starts at 0x0000020697fc1000
ephemeral segment allocation context: none
------------------------------
GC Heap Size: Size: 0x1241b3858 (4900730968) bytes.从最后一行可以看出托管堆占用 4900730968/1024/1024/10244.5G两个指标一比对原来是托管内存出问题了这下好办了。。。2. 查看托管堆既然内存是被托管堆吃掉了那就看看托管堆上到底都有些什么东西
0:000 !dumpheap -stat
Statistics:MT Count TotalSize Class Name
...
00007ffd00397b98 1065873 102323808 System.Data.DataRow
00000206978b8250 1507805 223310768 Free
00007ffd20d216b8 4668930 364025578 System.String
00007ffd20d22aa8 797 403971664 System.String[]
00007ffd20d193d0 406282 3399800382 System.Byte[]
Total 9442152 objects不看不知道一看吓一跳System.Byte[] 差不多占用了 3.3 G 内存也就是说 gc 堆差不多都被它吃掉了根据经验肯定是有个什么大对象那接下来怎么分析呢除了用脚本对 byte[] 进行暴力分组统计之外纯人肉还有其他的技巧吗? 当然有可以用 !heapstat 观察下这些对象在托管堆上的代信息。
0:000 !heapstat
Heap Gen0 Gen1 Gen2 LOH
Heap0 2252000 18880400 3968704192 910894376Free space: Percentage
Heap0 43128 770160 185203264 39849984SOH: 4% LOH: 4%从图中可以看出当前的大头在 Gen2 上接下来可以用 eeheap -gc 去找 Gen2 的段地址区间从而最小化的显示heap上内容。
0:000 !eeheap -gc
Number of GC Heaps: 1
generation 0 starts at 0x00000207a4fc48c8
generation 1 starts at 0x00000207a3dc3138
generation 2 starts at 0x0000020697fc1000
ephemeral segment allocation context: nonesegment begin allocated size
0000020697fc0000 0000020697fc1000 00000206a7fbec48 0xfffdc48(268426312)
00000206bbeb0000 00000206bbeb1000 00000206cbeaef50 0xfffdf50(268427088)
00000206ccc40000 00000206ccc41000 00000206dcc3f668 0xfffe668(268428904)
00000206dcc40000 00000206dcc41000 00000206ecc3f098 0xfffe098(268427416)
0000020680000000 0000020680001000 000002068ffff8c0 0xfffe8c0(268429504)
00000206ff4d0000 00000206ff4d1000 000002070f4cf588 0xfffe588(268428680)
000002070f4d0000 000002070f4d1000 000002071f4cf9f0 0xfffe9f0(268429808)
000002071f4d0000 000002071f4d1000 000002072f4cfef0 0xfffeef0(268431088)
000002072f4d0000 000002072f4d1000 000002073f4cf748 0xfffe748(268429128)
000002073f4d0000 000002073f4d1000 000002074f4ce900 0xfffd900(268425472)
00000207574d0000 00000207574d1000 00000207674cfe70 0xfffee70(268430960)
00000207674d0000 00000207674d1000 00000207774ceaf8 0xfffdaf8(268425976)
00000207774d0000 00000207774d1000 00000207874cf270 0xfffe270(268427888)
00000207874d0000 00000207874d1000 00000207974cf7a8 0xfffe7a8(268429224)
00000207974d0000 00000207974d1000 00000207a51ea5a8 0xdd195a8(231839144)一般来说第一个 segment 是给 gen0 gen1 的后续的 segment 就是 gen2接下来我就选 segment00000206dcc41000 - 00000206ecc3f098 然后使用 !dumpheap 导出该区间的所有对象。
0:000 !dumpheap -stat 00000206dcc41000 00000206ecc3f098
Statistics:MT Count TotalSize Class Name
00007ffd00397b98 191803 18413088 System.Data.DataRow
00007ffd20d216b8 662179 37834152 System.String
00007ffd20d193d0 23115 187896401 System.Byte[]从这个内存段上看Byte[] 有 2.3w 个还不算多全部dump出来看看有什么特征。
0:000 !dumpheap -mt 00007ffd20d193d0 00000206dcc41000 00000206ecc3f098Address MT Size
00000206dcc410e8 00007ffd20d193d0 8232
00000206dcc43588 00007ffd20d193d0 8232
00000206dcc45a48 00007ffd20d193d0 8232
00000206dcc47d78 00007ffd20d193d0 8232
00000206dcc4a028 00007ffd20d193d0 8232
00000206dcc4c4b0 00007ffd20d193d0 8232
00000206dcc4eb08 00007ffd20d193d0 8232
00000206dcc50e88 00007ffd20d193d0 8232
00000206dcc535b0 00007ffd20d193d0 8232
00000206dcc575d8 00007ffd20d193d0 8232
00000206dcc5a5a8 00007ffd20d193d0 8232
00000206dcc5cbf8 00007ffd20d193d0 8232
00000206dcc5eef8 00007ffd20d193d0 8232
00000206dcc611f8 00007ffd20d193d0 8232
00000206dcc634e8 00007ffd20d193d0 8232
00000206dcc657f0 00007ffd20d193d0 8232
00000206dcc67af8 00007ffd20d193d0 8232
00000206dcc69e00 00007ffd20d193d0 8232
...我去99% 都是 8232byte原来都是些 8k 的byte数组那到底谁在使用它用 !gcroot 查一下引用根。
0:000 !gcroot 00000206dcc410e8
Thread 8c1c:rsi: - 00000206983d5730 System.ServiceProcess.ServiceBase[]...- 000002069dcb6d38 OracleInternal.ConnectionPool.OraclePool...- 000002069dc949c0 OracleInternal.TTC.OraBufReader- 000002069dc94a70 System.Collections.Generic.List1[[OracleInternal.Network.OraBuf, Oracle.ManagedDataAccess]]- 00000206ab8c2200 OracleInternal.Network.OraBuf[]- 00000206dcc41018 OracleInternal.Network.OraBuf- 00000206dcc410e8 System.Byte[]从引用链来看貌似是被 OracleInternal.Network.OraBuf[] 持有着这就很疑惑了难道是 Oracle Sdk 出的bug把内存给搞崩了好奇心来了看一下元素个数和size各是多少
0:000 !do 00000206ab8c2200
Name: OracleInternal.Network.OraBuf[]
MethodTable: 00007ffcc7833c68
EEClass: 00007ffd20757728
Size: 4194328(0x400018) bytes
Array: Rank 1, Number of elements 524288, Type CLASS (Print Array)
Fields:
None0:000 !objsize 00000206ab8c2200
sizeof(00000206ab8c2200) -1086824024 (0xbf3861a8) bytes (OracleInternal.Network.OraBuf[])当前数组有 52w totalsize直接负数了????。3. 寻找问题代码知道现象之后接下来用 ILSpy 把 Oracle SDK 反编译看看最终一比对如下图所示原来m_tempOBList是内存暴涨的罪魁祸首这就很尴尬了它为什么会暴涨为什么不释放由于我对 Oracle 也不熟悉只能求助于神奇的 StackOverflow我去还真有天涯沦落人Huge managed memory allocation when reading (iterating) data with DbDataReader大概是说这种现象是 Oracle SDK 在读取 Clob 类型的字段有一个bug解决办法也很简单用完后就释放详情参见如下图4. 寻找真相既然帖子上是说读取 Clob 类型出的问题那就把所有线程栈都调出来看看此时的线程栈中是否有 Clob 的踪影从线程栈上看代码是通过 ToDataTable 方法将 IDataReader 转成 DataTable在转换过程中读取了大字段自然就有了 GetCompleteClobData也就是说完美命中帖子所说为了让结论更准确我就去挖一下当前的 DataReader 已经读了多少行了
0:028 !clrstack -a
OS Thread Id: 0xbab0 (28)
000000e78ef7d520 00007ffd00724458 System.Data.DataTable.Load(System.Data.IDataReader, System.Data.LoadOption, System.Data.FillErrorEventHandler)PARAMETERS:this no datareader (CLR reg) 0x00000206a530ac20loadOption no dataerrorHandler no data
0:028 !do 0x00000206a530ac20
Name: Oracle.ManagedDataAccess.Client.OracleDataReader
MethodTable: 00007ffcc7933b10
EEClass: 00007ffcc78efd30
Size: 256(0x100) bytes
File: D:\xxx.dll
Fields:
00007ffd20d23e98 4000337 d0 System.Int32 1 instance 1061652 m_RowNumber从 m_RowNumber 看已经读取了 106w 行一次性读取100w的记录不常见如果还有大字段的话那也是????????了。三总结 综合来看这次事故是因为一次性读取含有大字段的百万级数据到DataTable引发解决方案很简单自己通过 for 读取 DataReader在处理完 OracleClob 类型之后马上释放参考帖子代码
var item oracleDataReader.GetOracleValue(columnIndex);if (item is OracleClob clob)
{if (clob ! null){// use clob.Value ...clob.Close();}
}END工作中的你是否已遇到 ... 1. CPU爆高2. 内存暴涨3. 资源泄漏4. 崩溃死锁5. 程序呆滞等紧急事件全公司都指望着你能解决... 危难时刻才能展现你的技术价值作为专注于.NET高级调试的技术博主欢迎微信搜索: 一线码农聊技术免费协助你分析Dump文件希望我能将你的踩坑经验分享给更多的人。
