偷偷摘套内射激情视频,久久精品99国产国产精,中文字幕无线乱码人妻,中文在线中文a,性爽19p

記一次 .NET 某物流 API 系統(tǒng) CPU 爆高分析

作者：一線碼農(nóng)聊技術(shù)
開發(fā) 前端
這次CPU爆高事故，主要還是因?yàn)榕刻峤挥涗浂?導(dǎo)致 SqlSugar 在做參數(shù)的正則替換上耗費(fèi)了大量CPU時(shí)間所致，降低批量條數(shù)，通過小步快跑的方式盡可能的降低運(yùn)行線程的積壓，應(yīng)該就能解決這個(gè)問題。

一、背景

1. 講故事

前段時(shí)間有位朋友找到我，說他程序CPU直接被打滿了，讓我?guī)兔聪略趺椿厥?，截圖如下：

圖片圖片

看了下是兩個(gè)相同的程序，既然被打滿了那就抓一個(gè) dump 看看到底咋回事。

二、為什么會(huì)打滿

1. 真的被打滿了嗎

凡事都要用數(shù)據(jù)說話，我們使用 !tp 命令觀察一下。

0:014> !tp
logStart: 62
logSize: 200
CPU utilization: 100 %
Worker Thread: Total: 16 Running: 0 Idle: 16 MaxLimit: 32767 MinLimit: 8
Work Request in Queue: 0
--------------------------------------
Number of Timers: 8
--------------------------------------
Completion Port Thread:Total: 9 Free: 2 MaxFree: 16 CurrentLimit: 9 MaxLimit: 1000 MinLimit: 8

從卦象看果然是被打滿了，那為什么會(huì)滿呢？一般來(lái)說CPU高是線程抬起來(lái)的，接下來(lái)我們就從線程入手。

2. 線程都在做什么事情

要想觀察每個(gè)線程都在做什么，可以使用 ~*e !clrstack 命令，打完所有的線程棧后，明顯發(fā)現(xiàn)有 6 處在 System.Text.RegularExpressions.RegexReplacement.Replace 正則替換這里，截圖如下：

圖片圖片

0:021> ~14s
ntdll!NtWaitForSingleObject+0x14:
00007ff9`c5d4fa74 c3              ret
0:014> !clrstack
OS Thread Id: 0x6ee0 (14)
        Child SP               IP Call Site
000000AC6CBF99C8 00007ff9c5d4fa74 [HelperMethodFrame: 000000ac6cbf99c8] 
000000AC6CBF9AC0 00007ff942416c05 System.String.Create[[System.Text.SegmentStringBuilder, System.Text.RegularExpressions]](Int32, System.Text.SegmentStringBuilder, System.Buffers.SpanAction`2<Char,System.Text.SegmentStringBuilder>) 
000000AC6CBF9B20 00007ff942416aeb System.Text.SegmentStringBuilder.ToString()
000000AC6CBF9BA0 00007ff9422e62ac System.Text.RegularExpressions.RegexReplacement.Replace(System.Text.RegularExpressions.Regex, System.String, Int32, Int32)
000000AC6CBF9C70 00007ff9422e4ec6 System.Text.RegularExpressions.Regex.Replace(System.String, System.String, System.String, System.Text.RegularExpressions.RegexOptions) 
000000AC6CBF9CD0 00007ff941e157aa SqlSugar.UtilMethods.ReplaceSqlParameter(System.String, SqlSugar.SugarParameter, System.String)
000000AC6CBF9F80 00007ff941e42990 SqlSugar.SqlSugarProvider+d__245`1[[System.Int32, System.Private.CoreLib]].MoveNext()
000000AC6CBFA300 00007ff94190e93c System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start[[System.__Canon, System.Private.CoreLib]](System.__Canon ByRef)
000000AC6CBFA360 00007ff941e420bd SqlSugar.SqlSugarProvider.SaveQueuesProviderAsync[[System.Int32, System.Private.CoreLib]](Boolean, System.Func`3<System.String,System.Collections.Generic.List`1<SqlSugar.SugarParameter>,System.Threading.Tasks.Task`1>)
000000AC6CBFA3D0 00007ff941e41a52 SqlSugar.SqlSugarProvider+d__224.MoveNext()
000000AC6CBFA480 00007ff94190e93c System.Runtime.CompilerServices.AsyncMethodBuilderCore.Start[[System.__Canon, System.Private.CoreLib]](System.__Canon ByRef)
000000AC6CBFA4E0 00007ff941e418f4 SqlSugar.SqlSugarProvider.SaveQueuesAsync(Boolean)
000000AC6CBFA550 00007ff941e417fe SqlSugar.SqlSugarClient.SaveQueuesAsync(Boolean)
000000AC6CBFA5A0 00007ff941e4177e SqlSugar.SqlSugarScope.SaveQueuesAsync(Boolean)
000000AC6CBFA5F0 00007ff941e40fce xxx.Repository.BaseRepository`1+d__76[[System.__Canon, System.Private.CoreLib]].MoveNext()
...
000000AC6D4FAAF0 00007ff9422c9d0c xxx.xxxService+d__15.MoveNext()
...

從上面的 MoveNext 和 AsyncMethodBuilder 來(lái)看，這里用的是全異步寫法，分析起來(lái)那是一個(gè)頭大哈。。。不過仔細(xì)觀察是 SqlSugar 在替換sql參數(shù)的時(shí)候引發(fā)的，一般來(lái)說和 Regular 有關(guān)的操作都是蠻耗 CPU 的，然后順手看了下cpu配置也才 8 核，難怪 CPU 直接 100% 了。

0:014> !cpuid
CP  F/M/S  Manufacturer     MHz
 0  6,85,7  <unavailable>   2500
 1  6,85,7  <unavailable>   2500
 2  6,85,7  <unavailable>   2500
 3  6,85,7  <unavailable>   2500
 4  6,85,7  <unavailable>   2500
 5  6,85,7  <unavailable>   2500
 6  6,85,7  <unavailable>   2500
 7  6,85,7  <unavailable>   2500

3. SqlSugar 到底在做什么

要想知道做什么，逆向一下代碼就好，截圖如下：

圖片圖片

這種寫法好不好我就不評(píng)價(jià)了，至少簡(jiǎn)單粗暴，那為什么會(huì)很耗時(shí)呢？這就要扒一下 ReplaceSqlParameter 方法中的三個(gè)參數(shù)，尤其是 itemSql 字段，然后使用 !clrstack -a。

0:014> !clrstack -a
OS Thread Id: 0x6ee0 (14)
        Child SP               IP Call Site
000000AC6CBF9CD0 00007ff941e157aa SqlSugar.UtilMethods.ReplaceSqlParameter(System.String, SqlSugar.SugarParameter, System.String)
    PARAMETERS:
        itemSql (0x000000AC6CBF9F80) = 0x0000023d802e1020
        itemParameter (0x000000AC6CBF9F88) = 0x0000023c4bd3ae58
        newName (0x000000AC6CBF9F90) = 0x0000023ca9dd3328
    LOCALS:
        0x000000AC6CBF9F68 = 0x0000000000000000

0:014> !do 0x0000023d802e1020
Name:        System.String
MethodTable: 00007ff93caad698
EEClass:     00007ff93ca89d60
Tracked Type: false
Size:        21391508(0x1466894) bytes
File:        C:\Program Files\dotnet\shared\Microsoft.NETCore.App\6.0.12\System.Private.CoreLib.dll
String:      <String is invalid or too large to print>

Fields:
              MT    Field   Offset                 Type VT     Attr            Value Name
00007ff93ca99480  40002f2        8         System.Int32  1 instance         10695743 _stringLength
00007ff93c9fea10  40002f3        c          System.Char  1 instance               49 _firstChar
00007ff93caad698  40002f1       e8        System.String  0   static 0000023c3f5613a0 Empty

0:014> ?0n21391508 /0x400
Evaluate expression: 20890 = 00000000`0000519a

從卦中看，簡(jiǎn)直是嚇一跳，這個(gè) sql 居然高達(dá) 20M，????，難怪處理起來(lái)比較慢，很好奇這 20M 到底是個(gè)啥？我估計(jì) SqlSugar 也沒考慮到有這么大的 SQL 吧，那如何導(dǎo)出這 20M 數(shù)據(jù)呢？可以使用 .writemem 即可。

0:014> .writemem D:\testdump\1.txt 0x0000023d802e1020+0xc L?0x1466894
Writing 1466894 bytes......

這里稍微提醒下，大文本最好用 LogView 這種便捷工具，然后使用 Utf-16 的方式打開，截圖如下：

圖片圖片

看卦中信息看，應(yīng)該是 batch insert 的時(shí)候 SqlSugar 在替換參數(shù)，在正則上出不來(lái)，那到底是 SqlSugar考慮不周還是使用者問題 ?

4. 到底是誰(shuí)的問題

要想知道是誰(shuí)的問題就需要看下是什么操作引發(fā)的批量提交，我們回頭仔細(xì)研讀下調(diào)用棧，通過逆向 xxx.xxxService+d__15.MoveNext 方法，簡(jiǎn)化后的邏輯如下：

public async Task<bool> Savexxx(xxxRequest requestModel)
        {
            List<xxxDetailModel> list = new List<xxxDetailModel>();

            for (int i = 0; i < requestModel.xxxDetailList.Length; i++)
            {
                _xxxService.AddQueue(list);  //5w
            }

            return await _xxxService.SaveQueuesAsync() > 0;
        }

在 _xxxService.SaveQueuesAsync 的內(nèi)部就是通過 SqlSugarProvider 進(jìn)行的批量提交，接下來(lái)的問題是 list 到底有多少記錄呢？

0:021> !dso
OS Thread Id: 0x51f8 (21)
          SP/REG           Object Name
    00ac6cefae38     023c73d9c8a8 System.Collections.Generic.List<xxx.xxxDetailModel>
0:021> !do 023c73d9c8a8
Name:        System.Collections.Generic.List`1[[xxx.xxxDetailModel]]
MethodTable: 00007ff93e12a2f8
EEClass:     00007ff93cb65668
Tracked Type: false
Size:        32(0x20) bytes
File:        C:\Program Files\dotnet\shared\Microsoft.NETCore.App\6.0.12\System.Private.CoreLib.dll
Fields:
              MT    Field   Offset                 Type VT     Attr            Value Name
00007ff93cc6d000  4002095        8     System.__Canon[]  0 instance 0000023c52b36f18 _items
00007ff93ca99480  4002096       10         System.Int32  1 instance            30708 _size
00007ff93ca99480  4002097       14         System.Int32  1 instance            30708 _version
00007ff93cc6d000  4002098        8     System.__Canon[]  0   static dynamic statics NYI                 s_emptyArray

從卦中看當(dāng)前是 3w 多，我發(fā)現(xiàn)在其他線程中也有 6w 的，比如下面這個(gè)。

0:014> !dumpobj /d 23c49e90300
Name:        System.Collections.Generic.List`1[[xxx.xxxDetailModel]]
MethodTable: 00007ff93e12a2f8
EEClass:     00007ff93cb65668
Tracked Type: false
Size:        32(0x20) bytes
File:        C:\Program Files\dotnet\shared\Microsoft.NETCore.App\6.0.12\System.Private.CoreLib.dll
Fields:
              MT    Field   Offset                 Type VT     Attr            Value Name
00007ff93cc6d000  4002095        8     System.__Canon[]  0 instance 0000023c1042fca8 _items
00007ff93ca99480  4002096       10         System.Int32  1 instance            63532 _size
00007ff93ca99480  4002097       14         System.Int32  1 instance            63532 _version
00007ff93cc6d000  4002098        8     System.__Canon[]  0   static dynamic statics NYI                 s_emptyArray

有了這些前因后果，建議朋友一次性少提交一點(diǎn)，比如 5000 條一次觀察下效果如何。

三、總結(jié)

這次CPU爆高事故，主要還是因?yàn)?nbsp;批量提交記錄多 導(dǎo)致 SqlSugar 在做參數(shù)的正則替換上耗費(fèi)了大量CPU時(shí)間所致，降低批量條數(shù)，通過小步快跑的方式盡可能的降低運(yùn)行線程的積壓，應(yīng)該就能解決這個(gè)問題。

責(zé)任編輯：武曉燕 來(lái)源： 一線碼農(nóng)聊技術(shù)
CPU.NETAPI
相關(guān)推薦

2024-08-08 11:21:01

2021-10-27 07:30:32

.NETCPU論壇

2021-04-21 07:38:41

CPU游戲站程序

2022-10-24 07:48:37

.NETCPUGC

2023-05-12 17:42:22

CPUMES系統(tǒng)

2024-03-15 15:15:53

.NETCPU系統(tǒng)

2024-12-31 09:36:06

2021-05-17 07:43:06

Web站 CPU.NET

2023-11-01 10:46:12

.NET線程同步

2022-02-23 10:12:58

CPUWeb.NET

2025-09-05 02:22:00

.NETCRM物流行業(yè)

2023-04-06 10:52:18

2024-03-28 12:56:36

2021-04-29 07:33:40

內(nèi)存API程序

2024-07-01 13:00:24

.NET網(wǎng)絡(luò)邊緣計(jì)算

2022-01-17 21:28:36

管理系統(tǒng).NET

2023-06-29 17:55:00

.NET日志WinDbg

2024-07-09 11:51:20

Windows線程池源碼

2024-11-29 10:06:59

2025-10-29 01:11:00

.NET系統(tǒng)windows
點(diǎn)贊
收藏

51CTO技術(shù)棧公眾號(hào)