怎么看一个网站是不是织梦,jsp网站开发总结,小程序定制开发公司哪家好,有动效得网站一#xff1a;背景 1. 讲故事上个月有个老朋友找到我#xff0c;说他的站点晚高峰 CPU 会突然爆高#xff0c;发了两份 dump 文件过来#xff0c;如下图#xff1a;又是经典的 CPU 爆高问题#xff0c;到目前为止#xff0c;对这种我还是有一些经验可循的。抓 2-3 个 du… 一背景 1. 讲故事上个月有个老朋友找到我说他的站点晚高峰 CPU 会突然爆高发了两份 dump 文件过来如下图又是经典的 CPU 爆高问题到目前为止对这种我还是有一些经验可循的。抓 2-3 个 dump第一个有利于算两份 dump 中的线程时间差从而推算最耗时线程。第二个有时候你抓的dump刚好线程都处理完了cpu 还未真实回落所以分析这种dump意义不大我是吃了不少亏????????????。优先推测是否为 GC 捣鬼现在的码农都精怪精怪的基本不会傻傻的写出个死循环绝大部分都是遇到某种 资源密集型 或 计算密集型 场景下导致非托管的 GC 出了问题。好了有了这个先入为主的思路接下来就可以用 windbg 去占卜了。二windbg 分析 1. GC 捣鬼分析GC 捣鬼的本质是 GC 出现了回收压力尤其是对 大对象堆 的分配和释放大家应该知道 大对象堆 采用的是链式管理法不到万不得已 GC 都不敢回收它所以在它上面的分配和释放都是一种 CPU密集型 操作不信你可以去 StackOverflow 上搜搜 LOH 和 HighCPU 的关联关系????????????。2. 使用 x 命令搜索在 windbg 中有一个快捷命令 x 可用于在非托管堆上检索指定关键词检索之前先看看这个 dump 是什么 Framework 版本决定用什么关键词。
0:050 lmv
start end module name
00b80000 00b88000 w3wp (pdb symbols) c:\mysymbols\w3wp.pdb\0CED8B2D5CB84AEB91307A0CE6BF528A1\w3wp.pdbLoaded symbol image file: w3wp.exeImage path: C:\Windows\SysWOW64\inetsrv\w3wp.exeImage name: w3wp.exe
71510000 71cc0000 clr (pdb symbols) c:\mysymbols\clr.pdb\9B2B2A02EC2D43899F87AC20F11B82DF2\clr.pdbLoaded symbol image file: clr.dllImage path: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dllImage name: clr.dllBrowse all global symbols functions dataTimestamp: Thu Sep 3 03:30:58 2020 (5F4FF2F2)CheckSum: 007AC92BImageSize: 007B0000File version: 4.8.4261.0Product version: 4.0.30319.0
从 File version 上可以看出当前是基于 Net Framework 4.8 的好了用 x clr!SVR::gc_heap::trigger* 看看有没有触发 gc 的操作。
0:050 x clr!SVR::gc_heap::trigger*
71930401 clr!SVR::gc_heap::trigger_ephemeral_gc (protected: int __thiscall SVR::gc_heap::trigger_ephemeral_gc(enum gc_reason))
71665cf9 clr!SVR::gc_heap::trigger_gc_for_alloc (protected: void __thiscall SVR::gc_heap::trigger_gc_for_alloc(int,enum gc_reason,struct SVR::GCDebugSpinLock *,bool,enum SVR::msl_take_state))
71930a08 clr!SVR::gc_heap::trigger_full_compact_gc (protected: int __thiscall SVR::gc_heap::trigger_full_compact_gc(enum gc_reason,enum oom_reason *,bool))从输出信息看gc 果然在高速运转开心哈接下来看一下是哪一个线程触发了gc可以用 !eestack 把所有线程的托管和非托管堆栈打出来。从图中可以看到当前 50 号线程的 GetUserLoginGameMapIds() 方法进行的大对象分配 try_allocate_more_space 触发了 clr!SVR::gc_heap::trigger_gc_for_alloc GC回收操作最后 GC 通过 clr!SVR::GCHeap::GarbageCollectGeneration 进行回收既然在回收必然有很多线程正在卡死。接下来再看看有几个线程正在共同努力调用 GetUserLoginGameMapIds() 方法。到这里基本就能确定是 gc 捣的鬼。接下来的兴趣点就是 GetUserLoginGameMapIds() 到底在干嘛3. 分析 GetUserLoginGameMapIds() 方法接下来把方法的源码导出来使用 !name2ee 找到其所属 module然后通过 !savemodule 导出该 module 的源码。
0:050 !name2ee *!xxx.GetUserLoginGameMapIds
Module: 1c870580
Assembly: xxx.dll
Token: 0600000b
MethodDesc: 1c877504
Name: xxx.GetUserLoginGameMapIds(xxx.GetUserLoginGameMapIdsDomainInput)
JITTED Code Address: 1d5a2030
0:050 !savemodule 1c870580 E:\dumps\6.dll
3 ps in file
p 0 - VA2000, VASize112b8, FileAddr200, FileSize11400
p 1 - VA14000, VASize3c8, FileAddr11600, FileSize400
p 2 - VA16000, VASizec, FileAddr11a00, FileSize200打开导出的 6.dll为了最大保护隐私我就把字段名隐藏一下 GetUserLoginGameMapIds() 大体逻辑如下。
public GetUserLoginGameMapIdsDomainOutput GetUserLoginGameMapIds(GetUserLoginGameMapIdsDomainInput input)
{Listint xxxQueryable this._xxxRepository.Getxxx();ListUserLoginGameEntity list this._userLoginGameRepository.Where((UserLoginGameEntity u) u.xxx input.xxx, null, ).ToListUserLoginGameEntity();Listint userLoginGameMapIds (from u in list select u.xxx).ToListint();IEnumerableGetUserLoginGameMapIdsDomainOutput.GetUserLoginGameMapIdsDataDomainOutput source (from mc in (from mc in this._mapCategoryRepository.AsQueryable().ToListMapCategoryEntity()where userLoginGameMapIds.Any((int mid) mid mc.xxx) mapIdsQueryable.Any((int xxx) xxx mc.xxx)select mc).ToListMapCategoryEntity()join u in list on mc.xxx equals u.xxxselect new GetUserLoginGameMapIdsDomainOutput.GetUserLoginGameMapIdsDataDomainOutput{xxx mc.xxx,xxx ((u ! null) ? new DateTime?(u.xxx) : null).GetValueOrDefault(DateTime.Now)} into dgroup d by d.MapId).Select(delegate(IGroupingint, GetUserLoginGameMapIdsDomainOutput.GetUserLoginGameMapIdsDataDomainOutput g){GetUserLoginGameMapIdsDomainOutput.GetUserLoginGameMapIdsDataDomainOutput getUserLoginGameMapIdsDataDomainOutput new GetUserLoginGameMapIdsDomainOutput.GetUserLoginGameMapIdsDataDomainOutput();getUserLoginGameMapIdsDataDomainOutput.xxx g.Key;getUserLoginGameMapIdsDataDomainOutput.xxx g.Max((GetUserLoginGameMapIdsDomainOutput.GetUserLoginGameMapIdsDataDomainOutput v) v.xxxx);return getUserLoginGameMapIdsDataDomainOutput;});return new GetUserLoginGameMapIdsDomainOutput{Data source.ToListGetUserLoginGameMapIdsDomainOutput.GetUserLoginGameMapIdsDataDomainOutput()};
}看的出来这是一段EF读取DB的复杂写法朋友说这段代码涉及到了多张表的关联操作算是一个 资源密集型 的方法。4. 到底持有什么大对象方法逻辑看完了接下来看下 GetUserLoginGameMapIds() 方法到底分配了什么大对象触发了GC可以探究下 50 线程的调用栈使用 !clrstack -a 调出所有的 参数 局部 变量。
0:050 !clrstack -a
OS Thread Id: 0x11a0 (50)
Child SP IP Call Site
2501d350 7743c0bc [HelperMethodFrame: 2501d350]
2501d3dc 704fbab5 System.Collections.Generic.List1[[System.__Canon, mscorlib]].set_Capacity(Int32)PARAMETERS:this (CLR reg) 0x08053f6cvalue no dataLOCALS:no data2501d3ec 704fba62 System.Collections.Generic.List1[[System.__Canon, mscorlib]].EnsureCapacity(Int32)PARAMETERS:this no datamin no dataLOCALS:no data2501d3f8 70516799 System.Collections.Generic.List1[[System.__Canon, mscorlib]].Add(System.__Canon)PARAMETERS:this (CLR reg) 0x08053f6citem (CLR reg) 0x2d7b07bcLOCALS:no data从调用栈上看由于 EF 的读取逻辑需要向 List 中添加一条记录刚好触发了List的扩容机制就是因为这个扩容导致了GC大对象分配。那怎么看呢? 很简单先把 this (CLR reg) 0x08053f6c 中地址拿出来do一下 !do 0x08053f6c 调出 List。
0:050 !do 0x08053f6c
Name: System.Collections.Generic.List1[[xxx.MapCategoryEntity, xxx.Entities]]
MethodTable: 1e81eed0
EEClass: 70219c7c
Size: 24(0x18) bytes
File: C:\Windows\Microsoft.Net\assembly\GAC_32\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll
Fields:MT Field Offset Type VT Attr Value Name
701546bc 40018a0 4 System.__Canon[] 0 instance 168792c0 _items
701142a8 40018a1 c System.Int32 1 instance 32768 _size
701142a8 40018a2 10 System.Int32 1 instance 32768 _version
70112734 40018a3 8 System.Object 0 instance 00000000 _syncRoot
701546bc 40018a4 4 System.__Canon[] 0 static no information上面的 _size 32768 看到了吗刚好是 2的15次方由于再次新增必须要扩容List 在底层需分配一个 System.__Canon[65536] 的数组来存储老内容这个数组肯定大于 85000byte 这个大对象的界定值啦。如果有兴趣你可以看下 List 的扩容机制。
// System.Collections.Generic.ListT
private void EnsureCapacity(int min)
{if (_items.Length min){int num (_items.Length 0) ? 4 : (_items.Length * 2);if ((uint)num 2146435071u){num 2146435071;}if (num min){num min;}Capacity num;}
}public int Capacity
{get{return _items.Length;}set{if (value _size){ThrowHelper.ThrowArgumentOutOfRangeException(ExceptionArgument.value, ExceptionResource.ArgumentOutOfRange_SmallCapacity);}if (value _items.Length){return;}if (value 0){T[] array new T[value]; //这里申请了一个 int[65536] 大小的数组if (_size 0){Array.Copy(_items, 0, array, 0, _size);}_items array;}else{_items _emptyArray;}}
}三总结 知道了前因后果之后大概提三点优化建议。优化 GetUserLoginGameMapIds() 方法中的逻辑这是最好的办法。从 dump 上看也就 4核4G 的小机器提升下机器配置或许有点用。
0:017 !cpuid
CP F/M/S Manufacturer MHz0 6,63,2 GenuineIntel 22951 6,63,2 GenuineIntel 22952 6,63,2 GenuineIntel 22953 6,63,2 GenuineIntel 22950:017 !address -summary
--- Protect Summary (for commit) - RgnCount ----------- Total Size -------- %ofBusy %ofTotal
PAGE_READWRITE 878 1eccd000 ( 492.801 MB) 29.61% 12.03%没有特殊原因的话用 64bit 来跑程序打破 32bit 的 4G 空间限制这样也可以让gc拥有更大的堆分配空间。参考网址https://docs.microsoft.com/zh-cn/dotnet/standard/garbage-collection/fundamentals
