記一次 .NET遊戲站程式的 CPU 爆高分析

一線碼農發表於2021-04-21
遊戲

一：背景

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.pdb
    Loaded symbol image file: w3wp.exe
    Image path: C:\Windows\SysWOW64\inetsrv\w3wp.exe
    Image name: w3wp.exe
71510000 71cc0000   clr        (pdb symbols)          c:\mysymbols\clr.pdb\9B2B2A02EC2D43899F87AC20F11B82DF2\clr.pdb
    Loaded symbol image file: clr.dll
    Image path: C:\Windows\Microsoft.NET\Framework\v4.0.30319\clr.dll
    Image name: clr.dll
    Browse all global symbols  functions  data
    Timestamp:        Thu Sep  3 03:30:58 2020 (5F4FF2F2)
    CheckSum:         007AC92B
    ImageSize:        007B0000
    File version:     4.8.4261.0
    Product 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 sections in file
section 0 - VA=2000, VASize=112b8, FileAddr=200, FileSize=11400
section 1 - VA=14000, VASize=3c8, FileAddr=11600, FileSize=400
section 2 - VA=16000, VASize=c, FileAddr=11a00, FileSize=200

開啟匯出的 6.dll，為了最大保護隱私，我就把欄位名隱藏一下， GetUserLoginGameMapIds() 大體邏輯如下。


public GetUserLoginGameMapIdsDomainOutput GetUserLoginGameMapIds(GetUserLoginGameMapIdsDomainInput input)
{
	List<int> xxxQueryable = this._xxxRepository.Getxxx();
	List<UserLoginGameEntity> list = this._userLoginGameRepository.Where((UserLoginGameEntity u) => u.xxx == input.xxx, null, "").ToList<UserLoginGameEntity>();
	List<int> userLoginGameMapIds = (from u in list select u.xxx).ToList<int>();
	IEnumerable<GetUserLoginGameMapIdsDomainOutput.GetUserLoginGameMapIdsDataDomainOutput> source = (from mc in (from mc in this._mapCategoryRepository.AsQueryable().ToList<MapCategoryEntity>()
	where userLoginGameMapIds.Any((int mid) => mid == mc.xxx) && mapIdsQueryable.Any((int xxx) => xxx == mc.xxx)
	select mc).ToList<MapCategoryEntity>()
	join u in list on mc.xxx equals u.xxx
	select new GetUserLoginGameMapIdsDomainOutput.GetUserLoginGameMapIdsDataDomainOutput
	{
		xxx = mc.xxx,
		xxx = ((u != null) ? new DateTime?(u.xxx) : null).GetValueOrDefault(DateTime.Now)
	} into d
	group d by d.MapId).Select(delegate(IGrouping<int, 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.ToList<GetUserLoginGameMapIdsDomainOutput.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.List`1[[System.__Canon, mscorlib]].set_Capacity(Int32)
    PARAMETERS:
        this (<CLR reg>) = 0x08053f6c
        value = <no data>
    LOCALS:
        <no data>

2501d3ec 704fba62 System.Collections.Generic.List`1[[System.__Canon, mscorlib]].EnsureCapacity(Int32)
    PARAMETERS:
        this = <no data>
        min = <no data>
    LOCALS:
        <no data>

2501d3f8 70516799 System.Collections.Generic.List`1[[System.__Canon, mscorlib]].Add(System.__Canon)
    PARAMETERS:
        this (<CLR reg>) = 0x08053f6c
        item (<CLR reg>) = 0x2d7b07bc
    LOCALS:
        <no data>

從呼叫棧上看，由於 EF 的讀取邏輯需要向 List 中新增一條記錄剛好觸發了List的擴容機制，就是因為這個擴容導致了GC大物件分配。

那怎麼看呢? 很簡單，先把 this (<CLR reg>) = 0x08053f6c 中地址拿出來do一下 !do 0x08053f6c 調出 List。


0:050> !do 0x08053f6c
Name:        System.Collections.Generic.List`1[[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.List<T>
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];   //這裡申請了一個 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     MHz
 0  6,63,2  GenuineIntel    2295
 1  6,63,2  GenuineIntel    2295
 2  6,63,2  GenuineIntel    2295
 3  6,63,2  GenuineIntel    2295

 0: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

更多高質量乾貨：參見我的 GitHub: dotnetfly

圖片名稱

相關文章