记一次.NET某供应链Web网站CPU爆高事故分析

一、背景

1. 讲故事

我建议朋友用 procdump 在 cpu 高的时候连抓两个dump，这样分析起来比较稳健，朋友也如期的成功抓到，接下来就用 windbg 一起来分析下吧。

成都创新互联主营阜南网站建设的网络公司,主营网站建设方案,App定制开发,阜南h5微信小程序开发搭建,阜南网站营销推广欢迎阜南等地区企业咨询

二、Windbg 分析

1. 查看CPU占用率

先用 !tp 查看两个 dump 的cpu 利用率

0:112> !tp
CPU utilization: 100%
Worker Thread: Total: 138 Running: 128 Idle: 10 MaxLimit: 2000 MinLimit: 400
Work Request in Queue: 17
    Unknown Function: 00007ffe1a6617d0  Context: 000001fd9bcb20c8
    ...
--------------------------------------
Number of Timers: 2
--------------------------------------
Completion Port Thread:Total: 2 Free: 2 MaxFree: 16 CurrentLimit: 2 MaxLimit: 2000 MinLimit: 400


0:014> !tp
CPU utilization: 96%
Worker Thread: Total: 173 Running: 67 Idle: 106 MaxLimit: 2000 MinLimit: 400
Work Request in Queue: 1
    Unknown Function: 00007ffe1a6617d0  Context: 000001fda1a20be8
--------------------------------------
Number of Timers: 2
--------------------------------------
Completion Port Thread:Total: 7 Free: 7 MaxFree: 16 CurrentLimit: 7 MaxLimit: 2000 MinLimit: 400


果然如朋友所述，接下来就可以试探的看下是不是 GC 触发导致 ?

2. 查看是否 GC 触发

干脆一点就是用 ~*e !dumpstack 导出所有线程的托管和非托管栈，然后搜索 GarbageCollectGeneration 就好了。

果然是触发了 GC，从调用栈信息看，当前托管层可能正在高频的 new 操作，导致只往某一个heap上狂写数据从而致 heap 失衡，服务器模式GC为了让多 heap 均衡，做了 heap balance 操作，接下来的线索是为什么有狂写的情况?还得看下托管层，使用!clrstack 命令。

0:112> !clrstack 
OS Thread Id: 0x3278 (112)
        Child SP               IP Call Site
000000b4ddc79098 00007ffe28b9fa74 [HelperMethodFrame: 000000b4ddc79098] 
000000b4ddc791a0 00007ffda6c229cb System.Data.Entity.ModelConfiguration.Utilities.EdmPropertyPath.System.Collections.Generic.IEnumerable.GetEnumerator()
000000b4ddc79200 00007ffe01a179eb System.Linq.Enumerable.SequenceEqual[[System.__Canon, mscorlib]](System.Collections.Generic.IEnumerable`1, System.Collections.Generic.IEnumerable`1, System.Collections.Generic.IEqualityComparer`1)
000000b4ddc79280 00007ffda6c2297e System.Data.Entity.ModelConfiguration.Configuration.Mapping.EntityMappingConfiguration+c__DisplayClass14.b__11(System.Data.Entity.Core.Mapping.ColumnMappingBuilder)
000000b4ddc792b0 00007ffe01a13f8f System.Linq.Enumerable.SingleOrDefault[[System.__Canon, mscorlib]](System.Collections.Generic.IEnumerable`1, System.Func`2)
000000b4ddc79330 00007ffda6c2087c System.Data.Entity.ModelConfiguration.Configuration.Mapping.EntityMappingConfiguration.Configure(System.Data.Entity.Core.Metadata.Edm.DbDatabaseMapping, System.Data.Entity.Core.Common.DbProviderManifest, System.Data.Entity.Core.Metadata.Edm.EntityType, System.Data.Entity.Core.Mapping.StorageEntityTypeMapping ByRef, Boolean, Int32, Int32)
000000b4ddc79520 00007ffda6c20128 System.Data.Entity.ModelConfiguration.Configuration.Types.EntityTypeConfiguration.ConfigureUnconfiguredType(System.Data.Entity.Core.Metadata.Edm.DbDatabaseMapping, System.Data.Entity.Core.Common.DbProviderManifest, System.Data.Entity.Core.Metadata.Edm.EntityType)
000000b4ddc795a0 00007ffda6c1ffaf System.Data.Entity.ModelConfiguration.Configuration.Types.EntityTypeConfiguration.ConfigureTablesAndConditions(System.Data.Entity.Core.Mapping.StorageEntityTypeMapping, System.Data.Entity.Core.Metadata.Edm.DbDatabaseMapping, System.Data.Entity.Core.Common.DbProviderManifest)
000000b4ddc79620 00007ffda6c055c0 System.Data.Entity.ModelConfiguration.Configuration.ModelConfiguration.ConfigureEntityTypes(System.Data.Entity.Core.Metadata.Edm.DbDatabaseMapping, System.Data.Entity.Core.Common.DbProviderManifest)
000000b4ddc79680 00007ffda6c05474 System.Data.Entity.ModelConfiguration.Configuration.ModelConfiguration.Configure(System.Data.Entity.Core.Metadata.Edm.DbDatabaseMapping, System.Data.Entity.Core.Common.DbProviderManifest)
000000b4ddc796d0 00007ffda69ae5c2 System.Data.Entity.DbModelBuilder.Build(System.Data.Entity.Core.Common.DbProviderManifest, System.Data.Entity.Infrastructure.DbProviderInfo)
000000b4ddc79740 00007ffda6649ccf System.Data.Entity.DbModelBuilder.Build(System.Data.Common.DbConnection)
000000b4ddc79780 00007ffda7b4b2d3 System.Data.Entity.Infrastructure.EdmxWriter.WriteEdmx(System.Data.Entity.DbContext, System.Xml.XmlWriter)
000000b4ddc797c0 00007ffda7b4acbe Class125.smethod_0(System.Data.Entity.DbContext)
000000b4ddc79820 00007ffda7b4aba4 Class617.smethod_22(System.Data.Entity.DbContext)
000000b4ddc79860 00007ffda7b4aa90 Class617.smethod_27(System.Data.Entity.DbContext)
000000b4ddc798c0 00007ffda7b3e9ec DbContextExtensions.GetModel(System.Data.Entity.DbContext)
000000b4ddc79910 00007ffda7b3e49b Class124.smethod_0(System.Data.Entity.DbContext, System.String)
000000b4ddc79950 00007ffda7b3d6c3 Class486.smethod_3[[System.__Canon, mscorlib]](System.Data.Entity.DbContext, Z.BulkOperations.BulkOperation`1, System.Collections.Generic.IEnumerable`1, System.Collections.Generic.List`1)
000000b4ddc79a00 00007ffda7b36871 DbContextExtensions.BulkInsert[[System.__Canon, mscorlib]](System.Data.Entity.DbContext, System.Collections.Generic.IEnumerable`1, System.Action`1>)
000000b4ddc79ab0 00007ffda7b32c65 xxx.EFRepository`1[[System.__Canon, mscorlib]].BulkInsert(System.__Canon[])
...


从栈信息看，大概有如下三点信息：

  • 正在用 EF 做批量插入操作 BulkInsert。
  • 用了 Z.EntityFramework 插件。
  • 大量的 Build, Configure 字样，貌似是在做什么配置，构建啥的。

3. 是插入数据过多导致的吗?

第一个能想到的就是 list 过大，为了验证，可以用 !clrstack -a 把 BulkInsert 方法的 list 参数给导出来。

0:112> !clrstack -a
OS Thread Id: 0x3278 (112)
        Child SP               IP Call Site
000000b4ddc79b90 00007ffda7b31ee8 xxx.BLL.BaseService`1[[System.__Canon, mscorlib]].BulkInsert(System.__Canon[])
    PARAMETERS:
        this (0x000000b4ddc79d10) = 0x000001fa14bbb630
        _tArr (0x000000b4ddc79d18) = 0x000001fa14c1a2f8

0:112> !do 0x000001fa14c1a2f8
Name:        xxx.EntityModel.xxx[]
MethodTable: 00007ffda9437968
EEClass:     00007ffe02f556b0
Size:        56(0x38) bytes
Array:       Rank 1, Number of elements 4, Type CLASS (Print Array)
Fields:
None


从输出看，当前的list.length=4，这就很疑惑了，既然 heap 都在 balance ，那是不是有几个线程在猛攻?为了验证就用 DbContextExtensions.BulkInsert 在所有的托管线程栈上搜关键词看看。

可以看到当前有 10 处在猛攻，依次看他们的list都不大，疑惑哈。

4. 对问题的预判断

有了这些思路，但总觉得触发GC的由头太怪了，不过可以肯定的是问题出在了 Z.EntityFramework 插件上，按照 4S店的传统经验，只换不修肯定没问题，由于我对 Z.EntityFramework 不熟悉，也只能这样给到朋友了。

说来也奇怪，朋友第二天发现了一个奇怪现象，说每次 CPU 爆高之前都出现了一次 w3wp 的异常重启，而重启之后由于 Z.EntityFramework 需要预热，导致后续请求阻塞引发的 CPU 阶段性爆高。

从朋友的留言加上刚才的 dump 分析，问题基本就能定位了， Build, Configure 和 banlance 操作都能解释的通，而且还发现这个所谓的预热并没有做到串行化，而是10个线程一起来，直到预热结束，CPU 下降。

三、总结

总的来说，这次CPU阶段性爆高的事故是由于 w3wp 进程的意外重启，导致多线程并发对 Z.EntityFramework 预热，在预热的过程中导致了多次 GC 触发，至于 w3wp 为什么被意外终止，这就是另外一个话题了，不过好消息是朋友在后续的几天中从抓取的crash dump 中找到了问题代码。

网页名称：记一次.NET某供应链Web网站CPU爆高事故分析
当前地址：http://www.shufengxianlan.com/qtweb/news10/178810.html

网站建设、网络推广公司-创新互联，是专注品牌与效果的网站制作，网络营销seo公司；服务项目有等

广告

声明：本网站发布的内容（图片、视频和文字）以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-86922220；邮箱：631063699@qq.com。内容未经允许不得转载，或转载时需注明来源： 创新互联

猜你还喜欢下面的内容

关键词优化知识

分类信息网站

微信小程序公众号开发　　 　西部信息服务器托管　　 　公司宣传册设计　　 　软文发布平台　　 　普能电气　　 　营销型网站建设　　 　主动防护网　　 　网站维护　　 　香港虚拟主机　　 　中国电信成都枢纽中心　　 　云服务器　　 　四川乐山服务器托管　　 　成都商城网站开发　　 　全网品牌营销　　 　关键词排名　　 　成都酒店服定制　　 　贵阳托管服务器　　 　成都网站维护公司　　 　成都导视系统设计　　 　成都富士康招工