1. 首頁 > 生活百科 > >

記一次 .NET 某電子病歷 CPU 爆高分析( 二 )

生活百科

17min，所以 17min 觸發了至少 113 =90+23 次 FullGC 。
0:117> .timeDebug session time: Tue Sep6 15:56:08.000 2022 (UTC + 8:00)System Uptime: 0 days 21:59:52.396Process Uptime: 0 days 0:17:10.000Kernel time: 0 days 0:34:34.000User time: 0 days 0:39:05.000這個算頻繁嗎？觸發點是否集中？ 在DUMP這種照片下是不得而知的，為了穩一點再看看可有其他的線索 。
3. 還有其他線索嗎？既然線程池堆積了很多任務 ， 除了受到一些諸如 GC 的外因影響，內因肯定是最主要的 ， 既然都是 http 請求，可以用 !whttp 觀察各自的 HttpContext 。
0:117> !whttpHttpContextThread Time Out RunningStatus VerbUrl0000017b406b6f80102 00:05:00 00:08:56200 GET/xxxx/xxx/xxxLogOutputExcel0000017b46797110107 00:05:00 00:07:35200 GET/xxxx/xxx/xxxLogOutputExcel0000017b814572f897 00:05:00 00:08:49200 GET/xxxx/xxx/xxxLogOutputExcel0000017b84634490104 00:05:00 00:07:46200 GET/xxxx/xxx/xxxLogOutputExcel0000017bc04767b090 00:05:00 00:08:43200 GET/xxxx/xxx/xxxLogOutputExcel0000017e3e79cbb896 00:05:00 00:09:45200 GET/xxxx/xxx/xxxLogOutputExcel0000017e7ee10b8088 00:05:00 00:09:40200 GET/xxxx/xxx/xxxLogOutputExcel0000017e89b2cfb0109 00:05:00 00:04:37200 GET/xxxx/xxx/xxxLogOutputExcel0000017e8adb6b80106 00:05:00 00:02:53200 GET/xxxx/xxx/xxxLogOutputExcel0000017d41e90f28103 00:05:00 00:08:04200 GET/xxxx/xxx/xxxLogOutputExcel0000017d4385d528101 00:05:00 00:07:39200 GET/xxxx/xxx/xxxLogOutputExcel0000017d471b7d5898 00:05:00 00:06:50200 GET/xxxx/xxx/xxxLogOutputExcel0000017bc8283c48117 00:05:00 00:00:32200 GET/xxx/xxx/xxxMedTags...【記一次 .NET 某電子病歷 CPU 爆高分析】

記一次 .NET 某電子病歷 CPU 爆高分析

文章插圖
從卦中看，有兩點信息：
  1. 高達 17 個 Excel 導出請求 ， 一般來說導出操作都是 CPU 密集型的, 17 個請求可能剛好把 CPU 全部打滿，可以通過 !cpuid 驗證下 。
0:117> !cpuidCPF/M/SManufacturerMHz 06,79,1<unavailable>1995 16,79,1<unavailable>1995 26,79,1<unavailable>1995 36,79,1<unavailable>1995 46,79,1<unavailable>1995 56,79,1<unavailable>1995 66,79,1<unavailable>1995 76,79,1<unavailable>1995 86,79,1<unavailable>1995 96,79,1<unavailable>1995106,79,1<unavailable>1995116,79,1<unavailable>1995126,79,1<unavailable>1995136,79,1<unavailable>1995146,79,1<unavailable>1995156,79,1<unavailable>1995
  1. 觸發 GC 的請求是 /xxx/xxx/xxxMedTags 也高達 32s  ， 說明程序此時整體變慢 。
接下來就是把挖到的這兩點信息告訴朋友，重點是 xxxLogOutputExcel 導出，一定要限定頻次 。
三：總結總體來說這次生產事故誘發的因素有兩個：
  • 主因是客戶高頻次的點擊 Excel 導出，越著急越點，越點越著急 ， 導致系統的雪崩 。
  • 高頻的Excel點擊操作，間接導致 Spire.Pdf 在某一時段為了釋放非托管資源頻發的誘導 GC.Collect，進而雪上加霜 。
解決方案就簡單了，抑制高頻點擊 。
多一點耐心，少一點急躁 ， 也許我們相處的會更好 。
記一次 .NET 某電子病歷 CPU 爆高分析

文章插圖

推薦閱讀