前几天给一台跑定时任务的 VPS 做例行巡检,发现一个现象:白天一切正常,一到晚上八九点,CPU 使用率就顶到 100%,页面打开明显变慢,但业务流量并没有明显增长。这篇文章记录完整的排查过程,给可能遇到同类问题的朋友一个参考。
一、背景
这台 VPS 的负载其实不重:几个定时脚本,一个低流量站点,配置 2 核 4G。平时 CPU 使用率在 10% 左右,理论上不应该出现性能问题。定时任务集中在凌晨执行,白天几乎没有计算压力。
二、问题现象
晚高峰(20:00-22:00)出现以下特征:
-
CPU 使用率持续 100%,不是瞬时尖峰;
-
业务流量没有增长,排除了真实流量压力;
-
站点响应变慢,定时脚本执行时间比平时长 3-4 倍;
-
白天自动恢复,规律性强,每天如此。
三、排查过程
第一步:排除进程异常。 用 top 和 htop 查看进程列表,没有发现异常进程,CPU 是被业务进程占用的,不是挖矿或恶意进程。内存使用正常,没有 swap 抖动。
第二步:核对流量。 检查站点访问日志和带宽监控,访问量没有异常波动,排除流量攻击。
第三步:看 CPU 型号与配额。 检查 CPU 信息时发现,这台实例的 CPU 是共享型的,服务商文档里明确写着:共享型实例采用信用额度机制,CPU 使用率超过基线时会消耗突发额度,额度耗尽后会被限流到基线性能。
到这里,原因基本清楚了:定时任务虽然集中在凌晨,但任务执行期间 CPU 满载,把当天的突发额度提前耗尽;晚高峰即使业务流量不大,一旦有请求进来,CPU 已无额度可用,只能以基线性能运行,表现就是"莫名其妙变慢"。
四、根因分析
共享型实例的 CPU 配额模型是这样的:实例有基线性能(比如单核的 20%),持续超过基线会累积消耗"信用额度"(credits),额度充足时可以用满 CPU,额度耗尽后被强制限流到基线。
这台 VPS 的问题在于:凌晨的定时任务把 CPU 打满,一次性消耗了大量信用额度,白天低负载时额度缓慢恢复,但到晚上还没恢复完全,叠加少量请求,CPU 又被顶到 100%,形成"白天正常、晚上卡顿"的规律现象。
这类问题的隐蔽性在于:表面看是 CPU 100%,实际是额度耗尽后的限流,而不是真实算力不够。如果只看负载曲线,很容易误判成"配置不够,需要升级"。
五、解决方案
针对这次问题,做了三步调整:
-
错峰执行:把凌晨的定时任务拆开,分散到多个时段,避免一次性打满 CPU,让额度有恢复窗口;
-
限制并发:任务脚本里加了并发限制,同一时间最多跑两个任务,控制瞬时负载;
-
监控补齐:配置了 CPU 信用额度指标和基线使用率的告警,额度低于阈值时提前通知,不再等卡顿发生才排查。
调整后观察一周,晚高峰 CPU 使用率回落到 20% 左右,站点响应恢复正常,定时任务执行时间也回到正常水平。
六、复盘
这次排查有几个值得记录的教训:
-
共享型实例的 CPU 100%,不一定是算力不够,先确认是否额度限流,再谈升级;
-
负载曲线要结合配额机制看,持续满载比瞬时尖峰更容易触发限流;
-
监控要前置,CPU 信用额度这类指标应该在部署初期就配置告警,而不是出问题后补;
-
定时任务别挤在一起,错峰执行既省钱又稳定,是最低成本的优化手段。
