旅游网站建设规划书模板,南昌地宝网租房个人房源,装潢设计是什么,爱网盘一#xff1a;背景1. 讲故事前天写了一篇大内存排查在园子里挺火#xff0c;这是做自媒体最开心的事拉#xff0c;干脆再来一篇满足大家胃口#xff0c;上个月我写了一篇博客提到过使用bitmap对原来的ListCustomerID进行高强度压缩#xff0c;将原来的List内存压缩… 一背景1. 讲故事前天写了一篇大内存排查在园子里挺火这是做自媒体最开心的事拉干脆再来一篇满足大家胃口上个月我写了一篇博客提到过使用bitmap对原来的ListCustomerID进行高强度压缩将原来的List内存压缩了将近106倍但是bitmap不是一味的好你必须在正确的场景中使用而不是闭着眼睛滥用bitmap在C#中对应的集合是BitArray。好像剧透了????????????结果就是BitArray的滥用导致内存小10G的涨跌不过这种东西重点还是看解决思路写给以后的自己可不能让这难得的实践经验蒸发啦~~~二解决思路1. 一看托管堆看托管堆虽然是一个好主意但也不是每次都凑效毕竟造成内存暴涨暴跌的原因各种各样就像人感冒有风寒风热和病毒性对吧????还是使用老命令 !dumpheap -stat -min 102400 在托管堆上找大于100M的对象。
0:030 !dumpheap -stat -min 102400
Statistics:MT Count TotalSize Class Name
00007ffe094ec988 1 1438413 System.Byte[]
00007ffdab934c48 1 1810368 System.Collections.Generic.Dictionary2Entry[[System.Int32, mscorlib],[System.Collections.Generic.HashSet1[[System.Int64, mscorlib]], System.Core]][]
00007ffe094e6948 1 2527996 System.String
00007ffdab9ace78 4 29499552 System.Collections.Generic.Dictionary2Entry[[System.Int64, mscorlib],[System.DateTime, mscorlib]][]
00007ffe094e4078 4 267342240 System.String[]
00007ffe094e9220 135 452683336 System.Int32[]
00007ffdab8cd620 123 1207931808 System.Collections.Generic.HashSet1Slot[[System.Int64, mscorlib]][]
00007ffe094c8510 185 1579292760 System.Int64[]
00007ffdab9516b0 154 1934622720 System.Linq.Set1Slot[[System.Int64, mscorlib]][]
000001cc882de970 347 3660623866 Free
Total 1371 objects
去掉一些敏感类后再观察好像没有特别显眼的集合像 System.Int64[] ,System.Linq.Set1Slot[[System.Int64, mscorlib]][]一般都是用作其他集合的内存存储很多时候用!gcroort 抓不出来最大的反而是Free列有347个碎片高达 3.5G说明此时的大对象堆是一塌糊涂啊要是GC能帮忙压缩一下该多好????。2. 查看每一个线程的调用栈先惯性的偷窥一下程序中有多少个线程。
0:000 !threads
ThreadCount: 74
UnstartedThread: 0
BackgroundThread: 72
PendingThread: 0
DeadThread: 0
Hosted Runtime: noLock ID OSID ThreadOBJ State GC Mode GC Alloc Context Domain Count Apt Exception0 1 2958 000001cc882e5a40 2a020 Preemptive 0000000000000000:0000000000000000 000001cc882d8db0 1 MTA2 2 2358 000001cc883122c0 2b220 Preemptive 000001D41B132930:000001D41B1348A0 000001cc882d8db0 0 MTA (Finalizer)3 4 2204 000001cc883ae5d0 102a220 Preemptive 0000000000000000:0000000000000000 000001cc882d8db0 0 MTA (Threadpool Worker)5 7 278c 000001cca29d8ef0 202b220 Preemptive 000001D41AB53A98:000001D41AB55A58 000001cc882d8db0 1 MTA6 40 2a64 000001cca3048f10 1020220 Preemptive 0000000000000000:0000000000000000 000001cc882d8db0 0 Ukn (Threadpool Worker)7 46 e34 000001cca311c390 202b220 Preemptive 0000000000000000:0000000000000000 000001cc882d8db0 0 MTA8 47 27d8 000001cca3115e00 2b220 Preemptive 0000000000000000:0000000000000000 000001cc882d8db0 0 MTA...
可以看到当前有74个线程后台线程有72个接下来用 ~*e !clrstack 查看每个托管线程都在做什么由于内容太多我就节选一下了哈。0:000 ~*e !clrstack
OS Thread Id: 0x2d64 (29)Child SP IP Call Site
000000d908cfe698 00007ffe28646bf4 [GCFrame: 000000d908cfe698]
000000d908cfe768 00007ffe28646bf4 [HelperMethodFrame_1OBJ: 000000d908cfe768] System.Threading.Monitor.ObjWait(Boolean, Int32, System.Object)OS Thread Id: 0x214c (30)Child SP IP Call Site
000000d90957e6e8 00007ffe28646bf4 [GCFrame: 000000d90957e6e8]
000000d90957e7b8 00007ffe28646bf4 [HelperMethodFrame_1OBJ: 000000d90957e7b8] System.Threading.Monitor.ObjWait(Boolean, Int32, System.Object)OS Thread Id: 0x1dc0 (40)Child SP IP Call Site
000000d950ebe878 00007ffe28646bf4 [GCFrame: 000000d950ebe878]
000000d950ebe948 00007ffe28646bf4 [HelperMethodFrame_1OBJ: 000000d950ebe948] System.Threading.Monitor.ObjWait(Boolean, Int32, System.Object)OS Thread Id: 0x274c (53)Child SP IP Call Site
000000d9693fe518 00007ffe28646bf4 [GCFrame: 000000d9693fe518]
000000d9693fe5e8 00007ffe28646bf4 [HelperMethodFrame_1OBJ: 000000d9693fe5e8] System.Threading.Monitor.ObjWait(Boolean, Int32, System.Object)
000000d9693fe700 00007ffe09314d05 System.Threading.ManualResetEventSlim.Wait(Int32, System.Threading.CancellationToken)
000000d9693fe790 00007ffe0930d996 System.Threading.Tasks.Task.SpinThenBlockingWait(Int32, System.Threading.CancellationToken)
000000d9693fe800 00007ffe09c9b7a1 System.Threading.Tasks.Task.InternalWait(Int32, System.Threading.CancellationToken)
发现一个奇怪的现象有4个线程 29,30,40,53 在 Monitor.ObjWait 处卡住了从调用栈来看这四个家伙正在准备向Mongodb批量插入数据[InsertBatch]此时应该有其他的一个线程先行获取到了lock正在做InsertBatch这四个线程在等待如何觉得抽象了我画一张图3. 寻找insertbatch处的集合这里我就拿 30号线程说事从上图调用栈中你应该看到一个System.Collections.Generic.IEnumerable1System.__Canon从IEnumerable中可以猜测实现类应该是List或者HashSet这样的集合接下来用 !dso 把30号线程栈上的对象全部dump出来。从图中看应该就是这个 Listxxx.Common.GroupConditionCustomerIDCacheModel然后用!objsize ➕!do 给List量个尺寸并且dump一下。
0:030 !objsize 000001d3fa581518 sizeof(000001d3fa581518) 1487587080 (0x58aac708) bytes (System.Collections.Generic.List1[[DataMipCRM.Common.GroupConditionCustomerIDCacheModel, DataMipCRM.Common]])
0:030 !do 000001d3fa581518
Name: System.Collections.Generic.List1[[DataMipCRM.Common.GroupConditionCustomerIDCacheModel, DataMipCRM.Common]]
MethodTable: 00007ffdab9557d0
EEClass: 00007ffe08eb22a0
Size: 40(0x28) bytes
File: C:\Windows\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll
Fields:MT Field Offset Type VT Attr Value Name
00007ffe09478740 4001871 8 System.__Canon[] 0 instance 000001d3fa5b9bf8 _items
00007ffe094e9288 4001872 18 System.Int32 1 instance 1520 _size
00007ffe094e9288 4001873 1c System.Int32 1 instance 1520 _version
00007ffe094e6f28 4001874 10 System.Object 0 instance 0000000000000000 _syncRoot
00007ffe09478740 4001875 8 System.__Canon[] 0 static no information
可以看出list占用 1487587080/1024/10241.4G尼玛这么大吓人哈从_size看也就1520个说明重点都在 _items 数组里啦接下里用 da 把第一个item拿出来解剖下。
0:030 !da -length 1 -details 000001d3fa5b9bf8
Name: DataMipCRM.Common.GroupConditionCustomerIDCacheModel[]
MethodTable: 00007ffdab955e10
EEClass: 00007ffe08eaaa00
Size: 16408(0x4018) bytes
Array: Rank 1, Number of elements 2048, Type CLASS
Element Methodtable: 00007ffdab955740
[0] 000001d3fa581540Name: DataMipCRM.Common.GroupConditionCustomerIDCacheModelMethodTable: 00007ffdab955740EEClass: 00007ffdab94b9e8Size: 64(0x40) bytesFile: D:\LuneceService\DataMipCRM.Common.dllFields:MT Field Offset Type VT Attr Value Name00007ffdaac69258 4000589 28 ...oDB.Bson.ObjectId 1 instance 000001d3fa581568 _idk__BackingField00007ffe094e9288 400058a 20 System.Int32 1 instance 1901 ShopIdk__BackingField00007ffe094e6948 400058b 8 System.String 0 instance 000001d3f7154070 GroupConditionHasCodek__BackingField00007ffe094e6948 400058c 10 System.String 0 instance 000001cca7b46ac0 unitk__BackingField00007ffe094f1cb0 400058d 18 ...lections.BitArray 0 instance 000001d3fa581580 customeridArrayk__BackingField
从最后一行的Type列可以看到有一个 BitArray 类还是一样先量个尺寸再打出来。
0:030 !objsize 000001d3fa581580 sizeof(000001d3fa581580) 956008 (0xe9668) bytes (System.Collections.BitArray)
0:030 !do 000001d3fa581580
Name: System.Collections.BitArray
MethodTable: 00007ffe094f1cb0
EEClass: 00007ffe08ead968
Size: 40(0x28) bytes
File: C:\Windows\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll
Fields:MT Field Offset Type VT Attr Value Name
00007ffe094e9220 40017e2 8 System.Int32[] 0 instance 000001d5320c6d18 m_array
00007ffe094e9288 40017e3 18 System.Int32 1 instance 7647524 m_length
00007ffe094e9288 40017e4 1c System.Int32 1 instance 2 _version
00007ffe094e6f28 40017e5 10 System.Object 0 instance 0000000000000000 _syncRoot
从output中看这个bitarray占用 956008/1024/1024 0.91M真tmd的大看bit位有 764w 个说明有一个CustomerID7647524-1放在这里面问题基本上就算找到了现在终于知道内存为什么这么大算一下就出来了。四总结最后去问了下搬砖的为什么这么写是因为给客户展示的一张报表为了加速。。。将每一个点上的人群保存起来放在BitArray上然后进入Monogdb缓存这样客户后续选择某一个点进行 下钻 操作的话可以直接从mongodb中将BitArray的人群复原出来免去程序重复计算之苦因为每个点的人群具有排他性落在每个点上的人可能只有几十几百几千而偏偏这家客户有800w之多自然这个CustomerID就特别大了更不巧的就用了bitArray存少量的大数字这些赶在一起之后就是一个典型的滥用bitarray您说的
