作為一個程式設計師，每天工作中糟心的事情之一，莫過於自己用來編碼的計算機，執行速度忽然變得奇慢無比。尤其像我這種年過四旬仍然在一線從事編碼工作的老程式設計師來說，只有靠不斷提高單位時間的產出效率，來彌補和年輕程式設計師體力和精力上的差距。所以工作電腦效能忽然急劇下降，是一件讓我無法接受的事情。

作為一個在 SAP 領域工作了 15 年的開發人員(詳情參考我的文章：一個 SAP 開發工程師的成長史)，我已經記不清曾經幫助客戶解決過多少個 SAP 產品的效能問題了。SAP CRM，SAP Fiori 應用，SAP Cloud for Customer，當然還有最近兩年工作的 SAP 電商雲 UI 即 Spartacus 執行在 CCV2 上的效能問題。

在疫情爆發的 2020 年之前，不少效能問題都是我前往客戶現場，和客戶方的技術人員一起合作來得以解決的。在疫情遲遲沒有結束的當下，我分外留戀當時可以無拘無束出差的日子。

無論是 SAP 何種產品，當執行效能出現問題時，慣用的方式都是通過分析一些專門的效能監控工具記錄的執行時資料，根據處理人員的經驗來初步定位出可能引起效能問題的瓶頸，然後採取各種方式來驗證自己的猜想。從發現效能問題的蛛絲馬跡，到最後找到引起效能問題的罪魁禍首，在客戶業務流程比較複雜，流程中涉及到多個 SAP 元件，客戶自定義開發規模比較大的情況下，往往是一個痛苦的歷程，但給人帶來的成就感也隨之爆棚，遠遠勝過按部就班編寫完一個簡單的函式，實現一個簡單的功能。

大概是"醫者不自醫"的緣故，再加上我自己對 Windows 作業系統的熟悉程度，遠遠遜於我對 SAP 產品的瞭解，所以當自己的電腦執行出現效能問題時，我明顯底氣不足。雖然理論上來說，Windows 作業系統的效能問題，都可以通過把電腦交給 SAP 研究院 Local IT 同事那裡重灌系統來解決，但一想起系統安裝完畢後，要一一重新安裝兩位數的開發工具和搭建開發環境，我就頭痛得要命。

本文記錄近一年來我的工作電腦兩次遇到效能問題的經歷，希望能幫助到曾經遇到類似問題的朋友們。

我工作中使用的電腦是 Lenovo Thinkpad P53，它被定位為一款移動工作站，其配置如下圖，作業系統是 Windows10. 平時使用中體驗非常好，我非常滿意，美中不足的就是發熱量大，散熱風扇的噪音很響。

Windows10 從休眠中喚醒後效能急劇下降的問題

去年我遇到過一個問題，電腦執行效能忽然無緣無故下降到令人無法忍受的程度，比如開啟一個 Excel 要半分鐘，敲一個新字元進去，按 Ctrl + S 要五六秒才能儲存成功，平時 Spartacus ng build 命令不到一分鐘就能完成，現在要5分鐘。

前面說到，Lenovo Thinkpad P53 的發熱量非常大，因此我哪怕是離開座位10分鐘，也習慣通過開始選單裡的 Sleep 將其設定為睡眠狀態，讓機身溫度稍稍下降一些。後來我發現一個規律，這個效能問題只有每次從睡眠模式中喚醒後才會出現。如果我當天開機後，一次也不進入睡眠模式，那麼一直到我關機為止，電腦都始終正常執行。

當出現效能問題時，我開啟 Windows 工作管理員，觀察到 System interrupts(系統中斷) 這個系統程序的 CPU 佔用率非常高。

按照微軟官方文件，系統中斷程序是 Windows 作業系統的組成部分之一，負責管理計算機硬體和作業系統之間的通訊。工作管理員中 System interrupts 程序顯示所有硬體中斷的 CPU 使用率。

系統中斷好比是 CPU 的警報系統，如果某個場景需要 CPU 關注，系統中斷會提醒處理器，當前有個高優先順序的任務需要執行，然後 CPU 暫停它正在做的事情，儲存上下文，並處理這個高優先順序的任務。一旦工作完成，CPU 就會恢復到發生中斷之前的狀態。

微軟官方文件介紹，正常情況下系統中斷程序的 CPU 佔用率在 0.1% 到 2% 之間。有時它會上升到 7%，這也被認為是正常的。但是當其在工作管理員顯示的 CPU 利用率飆升且居高不下時，往往意味著一些硬體層面的錯誤，或者是硬體的驅動程式出現了問題。

於是我就試著在 Google 上根據關鍵字 Windows System Interrupts CPU High Sleep Wakeup 這些關鍵字的排列組合，根據一條條搜尋出來的帖子，開始了漫長而艱難的 "修改系統設定->重啟" 的反覆試驗，最終一個帖子給出的解決方案，讓我有了得救的感覺。

Windows 裝置管理器裡，選中網路介面卡，右鍵選單裡選擇屬性：

然後在高階選項卡里，禁用 Wake on Magic Packet 和 Wake on pattern match 後，問題解決。以後每次系統從睡眠模式中恢復，再也沒有出現效能問題。

工作管理員裡沒有任何異常時的效能問題

上面介紹的問題解決之後，電腦一直正常執行，直到上個月，效能問題再次出現。整個作業系統無論執行任何任務耗費的時間，都變成以前的三倍到四倍。並且這次更詭異的是，工作管理員裡所有的程序 CPU 佔用率沒有任何異常，系統中斷程序的佔用率一直穩定在 0.1% ~ 2% 之間，說明這次不是硬體驅動引起的問題。

因為程序的 CPU 佔用率沒有任何異常，我也不知道該怎麼繼續分析這個問題了。一天深夜，我對著幾乎癱瘓的電腦發呆，忽然覺得有什麼事情不對勁：我的書房非常安靜，平時夜晚陪伴著我工作的只有 P53 呼呼的風扇聲音，但是現在有點不對勁，我即使把頭貼著電腦，也聽不到一絲一毫風扇轉動的聲音。此刻我電腦上仍然開著 Visual Studio Code 和十幾個 Chrome 視窗。如果不是電腦顯示屏仍然亮著，真的會讓人懷疑電腦是不是真的處於開機狀態。

這顯然不正常。難道散熱風扇壞了？我開啟 Intel 官方的 CPU 執行狀態監控軟體，Intel Power Gadget，發現了問題所在。P53 Intel(R) Core(TM) i9-9880H CPU 的額定主頻為 2.3G Hz, 但是 Power Gadget 測試出來的實際執行頻率只有 0.8G Hz, 這主頻簡直退化成了我 2001 年還在上大學時，寢室桌上型電腦用過的另一款經典的 Intel CPU，Pentium III-800.

CPU 主頻從 2300M Hz 一下驟降到 800M Hz，怪不得帶不動 Windows 10 和在上面執行的這些應用軟體啊。

不僅如此，在溫度監控視窗，我還發現了 PROC HOT Alert. 至此我的思路已經很清晰了，我的這臺 P53 的散熱風扇肯定出問題了。

第二天，我在微信上同公司的 Local IT 聯絡。我的初步分析：

降頻的原因，是因為系統檢測到了一個 PROC HOT 的訊號。Intel 官網文件，記錄這個訊號是 CPU 核心溫度超過了 TCC 系統設定的閾值之後，系統讓 CPU 降頻使用的一種保護措施，但是溫度監控軟體裡當前CPU 溫度不到五十度，不知道為何會觸發這個 PROC HOT 訊號。

另外一點就是我膝上型電腦前段時間風扇的聲音非常大，這幾天完全靜音了，讓我懷疑：

1. CPU 風扇損壞
2. 膝上型電腦主機板的溫控探頭相關的線路損壞，導致無法正確的檢測到 CPU 溫度，從而錯誤發出了 PROC HOT 訊號，導致 CPU 降頻使用，在低功耗下執行。風扇也就沒有轉或者說轉速大幅度下降了。

既然已經做出了猜測，驗證也就不難了。我們聯絡了聯想的維修工程師，把電腦大卸八塊，果然發現是風扇的問題。

散熱風扇的軸承磨損已經比較嚴重了，潤滑油也幾乎耗盡了。更換了一個新的風扇之後，問題解決。

聯想工程師介紹，P53 的風扇轉速由系統控制，根據晶片溫度和 CPU 負載會發生動態變化。我從 2007 年進入 SAP 成都研究院至今已經先後用過多款 Thinkpad 的膝上型電腦，每一款的散熱風扇都非常耐用，能夠堅持三年的正常使用。我這款 P53 也已經服役 2 年多了，可能是今年夏天成都幾十年難遇的持續高溫，導致它的散熱風扇提前耗盡了壽命。

本文介紹了筆者工作過程中先後遇到的兩個因為軟體和硬體故障，造成的效能問題的分析思路和解決辦法，希望對遇到過類似問題的朋友有所幫助。