作为一个程序员，每天工作中糟心的事情之一，莫过于自己用来编码的计算机，运行速度忽然变得奇慢无比。尤其像我这种年过四旬仍然在一线从事编码工作的老程序员来说，只有靠不断提高单位时间的产出效率，来弥补和年轻程序员体力和精力上的差距。所以工作电脑性能忽然急剧下降，是一件让我无法接受的事情。

作为一个在 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® Core™ 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 信号。

另外一点就是我笔记本电脑前段时间风扇的声音非常大，这几天完全静音了，让我怀疑：

CPU 风扇损坏
笔记本电脑主板的温控探头相关的线路损坏，导致无法正确的检测到 CPU 温度，从而错误发出了 PROC HOT 信号，导致 CPU 降频使用，在低功耗下运行。风扇也就没有转或者说转速大幅度下降了。

既然已经做出了猜测，验证也就不难了。我们联系了联想的维修工程师，把电脑大卸八块，果然发现是风扇的问题。

散热风扇的轴承磨损已经比较严重了，润滑油也几乎耗尽了。更换了一个新的风扇之后，问题解决。

联想工程师介绍，P53 的风扇转速由系统控制，根据芯片温度和 CPU 负载会发生动态变化。我从 2007 年进入 SAP 成都研究院至今已经先后用过多款 Thinkpad 的笔记本电脑，每一款的散热风扇都非常耐用，能够坚持三年的正常使用。我这款 P53 也已经服役 2 年多了，可能是今年夏天成都几十年难遇的持续高温，导致它的散热风扇提前耗尽了寿命。