.NET 某券商論壇系統(tǒng)卡死問題分析
一：背景
1. 講故事
前幾個(gè)月有位朋友找到我，說他們的的web程序沒有響應(yīng)了，而且監(jiān)控發(fā)現(xiàn)線程數(shù)特別高，內(nèi)存也特別大，讓我?guī)兔匆幌略趺椿厥拢F(xiàn)在回過頭來幾經(jīng)波折，回味價(jià)值太濃了。
二：程序到底經(jīng)歷了什么
1. 在線程上找原因
這個(gè)程序內(nèi)存高，線程高，無響應(yīng)，尼瑪是一個(gè)復(fù)合態(tài)問題，那怎么入手呢？按經(jīng)驗(yàn)推測，大概率是由于高線程數(shù)引發(fā)的，相信大家都知道每個(gè)線程都有自己的棧空間，所以眾人拾柴火焰高，可以用 !address -summary 觀察下線程?？臻g。
0:000> !address -summary --- Usage Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal Free 329 7df9`d4b93000 ( 125.976 TB) 98.42% <unknown> 994 205`2ae2e000 ( 2.020 TB) 99.81% 1.58% Stack 7215 0`e0d00000 ( 3.513 GB) 0.17% 0.00% Heap 956 0`1695f000 ( 361.371 MB) 0.02% 0.00% Image 1468 0`07b34000 ( 123.203 MB) 0.01% 0.00% TEB 2405 0`012ca000 ( 18.789 MB) 0.00% 0.00% Other 10 0`001d1000 ( 1.816 MB) 0.00% 0.00% PEB 1 0`00001000 ( 4.000 kB) 0.00% 0.00% ... --- State Summary ---------------- RgnCount ----------- Total Size -------- %ofBusy %ofTotal MEM_FREE 329 7df9`d4b93000 ( 125.976 TB) 98.42% MEM_RESERVE 3132 203`e925c000 ( 2.015 TB) 99.56% 1.57% MEM_COMMIT 9917 2`42201000 ( 9.033 GB) 0.44% 0.01%
從卦中可以清晰的看到，提交內(nèi)存是9G，同時(shí)Stack吃掉了3.5G，一般來說 Stack 不會(huì)有這么大，所以此事必有妖，在 TEB 中可以看到線程數(shù)高達(dá) 2405 個(gè)，這個(gè)確實(shí)不少哈，可以用 !t 做一個(gè)驗(yàn)證。
0:000> !t
ThreadCount: 2423
UnstartedThread: 0
BackgroundThread: 2388
PendingThread: 0
DeadThread: 34
Hosted Runtime: no
Lock
DBG ID OSID ThreadOBJ State GC Mode GC Alloc Context Domain Count Apt Exception
0 1 3344 00000032972B2D90 202a020 Preemptive 0000000000000000:0000000000000000 0000003297125a30 -00001 MTA
11 2 1d28 00000037A43B9140 2b220 Preemptive 000000364BC5AD90:000000364BC5C328 0000003297125a30 -00001 MTA (Finalizer)
12 5 2a00 00000037A52BF4D0 102a220 Preemptive 00000036527EBDE8:00000036527EDD90 0000003297125a30 -00001 MTA (Threadpool Worker)
13 7 3168 00000037A52C1B40 302b220 Preemptive 00000034D1136688:00000034D1137FD0 0000003297125a30 -00001 MTA (Threadpool Worker)
15 14 13b8 00000037A542EA50 202b220 Preemptive 00000036527EBCA8:00000036527EBD90 0000003297125a30 -00001 MTA
...有了這個(gè)入口點(diǎn)，接下來觀察每一個(gè)線程的線程棧，使用 ~*e !clrstack發(fā)現(xiàn)有大量的線程在 PostMethod 方法中的 Task.Result 上等待，看樣子是在做網(wǎng)絡(luò)請(qǐng)求，這里做了一下提前截?cái)?，截圖如下：
由于是知名券商，這里就盡量模糊了哈。。。請(qǐng)見諒，知道了在 Task.Result 上，一下子就開心起來了，自此也被誤入歧途。。。。
2. 誤入歧途
- 是上下文導(dǎo)致的嗎？
過往經(jīng)驗(yàn)告訴我，很多時(shí)候的 Task.Result 卡死是因?yàn)樯舷挛牡年P(guān)系所致，所以重點(diǎn)看下是不是 Asp.NET 的程序，使用 !eeversion 觀察便知。
0:000> !eeversion 6.0.422.16404 free 6,0,422,16404 @Commit: be98e88c760526452df94ef452fff4602fb5bded Server mode with 8 gc heaps SOS Version: 7.0.8.30602 retail build
從卦中數(shù)據(jù)看當(dāng)前是 .net6 寫的程序，就不存在上下文一說了，這個(gè)情況可以排除，只能繼續(xù)尋找其他突破口。。。
- 下游處理過慢導(dǎo)致的嗎？
是不是下游處理過慢，一個(gè)突破點(diǎn)就是觀察下 線程池隊(duì)列 是不是有任務(wù)積壓，這個(gè)可以用 !tp 觀察下隊(duì)列即可。
從卦中數(shù)據(jù)看當(dāng)前隊(duì)列無任何積壓，說明也不是下游處理過慢導(dǎo)致的，我去，太難了。。。
- 代理或者服務(wù)器有問題嗎？
既然無上下文，無積壓，接下來只能懷疑是不是server方有問題或者用了什么代理軟件？要想找這個(gè)信息，需要用 !dso 觀察線程棧中的對(duì)象。
0:000> ~34s ntdll!NtWaitForMultipleObjects+0xa: 00007ffe`115c0cba c3 ret 0:034> !dso OS Thread Id: 0x1ef4 (34) RSP/REG Object Name 00000037B56AC688 000000351f9e4918 System.Threading.Thread 00000037B56AC700 0000003317bb6160 System.Net.Http.DiagnosticsHandler 00000037B56AC708 000000351f9e4918 System.Threading.Thread 00000037B56AC748 0000003617b743c8 System.Net.Http.HttpWindowsProxy ... 00000037B56AD0D0 00000034c8283750 System.String http://xxx/Article/xxx 00000037B56ACF30 0000003317bb5ad8 System.Net.Http.HttpClient ...
看了下卦中的請(qǐng)求地址：http://xxx/Article/xxx， 同時(shí)在 HttpWindowsProxy 和 HttpClient 中也沒有看到所謂的代理IP，這就陷入了迷茫。
事已至此，只能懷疑是網(wǎng)絡(luò)的問題，讓朋友在程序卡死的那個(gè)期間段用 wireshark 或者 tcpdump 去抓下包，看看是不是網(wǎng)絡(luò)出了問題，tcp握手揮手怎么樣，事情也就這樣不了了之了。
3. 迷途知返
前些天在給訓(xùn)練營的朋友準(zhǔn)備課件時(shí)，優(yōu)化了一個(gè)例子來演示 線程池隊(duì)列 的堆積情況，結(jié)果意外發(fā)現(xiàn) sos 吐出來的數(shù)據(jù)是假的，尼媽，如夢初醒，分析dump已經(jīng)夠難了，為什么 sos 還要欺騙我，天真的塌下來了。。。
其實(shí)在分析 .net core 的dump時(shí)，每每發(fā)現(xiàn)線程池隊(duì)列都是 0 ，雖然有一絲奇怪，但也不敢懷疑sos吐出來的數(shù)據(jù)權(quán)威性。
既然 sos 吐出來的數(shù)據(jù)是假的，只能自己去線程池中把隊(duì)列挖出來，即 ThreadPoolWorkQueue.workItems 字段，如下所示：
0:034> !DumpObj /d 0000003517b9c1c0
Name: System.Threading.ThreadPoolWorkQueue
MethodTable: 00007ffd8416d260
EEClass: 00007ffd84196ab8
Tracked Type: false
Size: 168(0xa8) bytes
File: C:\Program Files\dotnet\shared\Microsoft.NETCore.App\6.0.4\System.Private.CoreLib.dll
Fields:
MT Field Offset Type VT Attr Value Name
00007ffd83ddbf28 4000c61 18 System.Boolean 1 instance 0 loggingEnabled
00007ffd83ddbf28 4000c62 19 System.Boolean 1 instance 0 _dispatchTimeSensitiveWorkFirst
00007ffd8416dc78 4000c63 8 ...Private.CoreLib]] 0 instance 0000003517b9c268 workItems
00007ffd8416e458 4000c64 10 ...Private.CoreLib]] 0 instance 0000003517b9eea0 timeSensitiveWorkQueue
00007ffd8416d1f0 4000c65 20 ...acheLineSeparated 1 instance 0000003517b9c1e0 _separated
...
0:034> !ext dcq 0000003517b9c268
System.Collections.Concurrent.ConcurrentQueue<System.Object>
1 - dumpobj 0x00000032c93b7ce0
2 - dumpobj 0x00000032c93b8ae8
3 - dumpobj 0x00000032c93b98d8
...
54346 - dumpobj 0x00000034d12fb2e8
54347 - dumpobj 0x0000003652805b40
---------------------------------------------
54347 items從卦中數(shù)據(jù)看當(dāng)前線程池堆積了 5.3w 的任務(wù)，很顯然是屬于第二種情況，即下游處理不及，既然處理不急，是不是遇到了什么高峰期呢？這個(gè)可以用 .time 觀察下當(dāng)前時(shí)段。
從卦中數(shù)據(jù)看，看樣子是快到 收盤時(shí)間 了，結(jié)合今年的大盤形式，看樣子是出現(xiàn)了暴跌，股民們?cè)诎l(fā)泄情緒，哈哈。。。
找到了問題的根，解決方案就比較多了。
做 PostMethod 請(qǐng)求的異步化，不要用 Result 去硬等待。
盡量做批量化提交，降低請(qǐng)求接口的單次時(shí)間。
三：總結(jié)
這次生產(chǎn)事故的分析峰回路轉(zhuǎn)，本來是一個(gè)很容易就能定位出的問題，可我認(rèn)為權(quán)威的sos居然吐出了假數(shù)據(jù)欺騙了我，讓我誤入歧途，浪費(fèi)了很多的人力物力，真的很無語。。。再也不相信 sos 了！
到此這篇關(guān)于.NET 某券商論壇系統(tǒng)卡死問題分析的文章就介紹到這了,更多相關(guān).NET 某券商論壇系統(tǒng)卡死內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！
相關(guān)文章
干貨來襲! 為大家分享了C# 7.0 新特性，VS2017可用，具有一定的參考價(jià)值，感興趣的小伙伴們可以參考一下2017-03-03
asp.net Ext grid 顯示列表實(shí)現(xiàn)代碼。2009-08-08
asp.net mvc webapi 實(shí)用的接口加密方法示例
本篇文章主要介紹了asp.net mvc webapi 實(shí)用的接口加密方法示例，具有一定的參考價(jià)值，感興趣的小伙伴們可以參考一下2017-10-10
http轉(zhuǎn)https的實(shí)戰(zhàn)記錄（iis 7.5）
這篇文章主要給大家介紹了關(guān)于http轉(zhuǎn)https的相關(guān)資料，文中是最近的一次實(shí)戰(zhàn)記錄，基于iis7.5，通過一步步的圖文介紹的非常詳細(xì)，對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，需要的朋友們下面來一起看看吧。2018-01-01
這篇文章主要為大家詳細(xì)介紹了ASP.NET MVC分頁問題的解決方法，Ajax.Pager分頁的使用注意事項(xiàng)，具有一定的參考價(jià)值，感興趣的小伙伴們可以參考一下2017-01-01
為ASP.NET MVC及WebApi添加路由優(yōu)先級(jí)
這是一個(gè)對(duì)Asp.Net Mvc的一個(gè)很小的功能拓展，小項(xiàng)目可能不太需要這個(gè)功能，但有時(shí)候項(xiàng)目大了注冊(cè)的路由不生效時(shí)你應(yīng)該要想到有可能是因?yàn)槁酚身樞虻脑颍@時(shí)這個(gè)路由優(yōu)先級(jí)的功能有可能就會(huì)給你帶來便利。2015-10-10
.NET/ASP.NET Routing路由(深入解析路由系統(tǒng)架構(gòu)原理)
這篇文章主要介紹了.NET/ASP.NET Routing路由(深入解析路由系統(tǒng)架構(gòu)原理)，小編覺得挺不錯(cuò)的，現(xiàn)在分享給大家，也給大家做個(gè)參考。一起跟隨小編過來看看吧2018-07-07
這篇文章主要介紹了NetCore?配置Swagger的方法，通過添加Nuget和添加靜態(tài)類擴(kuò)展方法，本文給大家介紹的非常詳細(xì)，對(duì)大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值,需要的朋友可以參考下2022-09-09
.net6簡單使用NPOI讀取Excel的項(xiàng)目實(shí)踐
本文主要介紹了.net6簡單使用NPOI讀取Excel的項(xiàng)目實(shí)踐，文中通過示例代碼介紹的非常詳細(xì)，對(duì)大家的學(xué)習(xí)或者工作具有一定的參考學(xué)習(xí)價(jià)值，需要的朋友們下面隨著小編來一起學(xué)習(xí)學(xué)習(xí)吧2022-06-06
.net jMail郵件發(fā)送(含抄送、密送、多發(fā)、日志記錄)實(shí)例代碼
這篇文章主要介紹了.net jMail郵件發(fā)送(含抄送、密送、多發(fā)、日志記錄)實(shí)例代碼，有需要的朋友可以參考一下2013-11-11