t2.medium服务器突发大量Stolen CPU峰值问题求助

问题描述 #

我们有一台AWS t2.medium服务器，此前稳定运行数周，突然出现大量Stolen CPU峰值，同时Spring Boot应用报线程池执行器已满错误。已排查确认无突发流量增长，且存在以下关键现象：

• 该实例是负载均衡后的4台同配置实例之一，其余3台运行完全正常
• 重启实例后问题仍存在，但停止实例并让AWS创建新实例后，Stolen CPU峰值彻底消失
• Stolen CPU峰值严格按5分钟间隔出现，已排查应用及系统配置，未发现任何每5分钟触发的任务，且即便存在周期任务也无法解释为何会标记为Stolen CPU

求助：有没有人遇到过类似问题？可能的根因是什么？

可能的根因与排查思路 #

1. AWS共享宿主机资源竞争（最可能） #

t2系列是AWS的共享型实例，多个租户的实例会共享同一物理宿主机的CPU资源。当宿主机上其他租户的实例存在5分钟周期的高CPU任务时，会抢占大量CPU时间，导致你的实例被“偷走”CPU，表现为Stolen CPU峰值。

• 重启实例只是重启虚拟机，AWS通常会将重启的实例放回原宿主机，因此问题持续；而创建新实例时，AWS会调度到其他空闲宿主机，避开资源竞争，问题自然消失。

2. 隐藏的系统/代理级周期任务 #

虽然排查了应用和常规定时任务，但可能存在以下隐藏的周期进程：

• AWS底层注入的代理进程：比如CloudWatch Agent或其他AWS系统代理，可能存在异常的5分钟周期采集任务，导致资源占用或误报Stolen CPU
• 系统内核周期操作：比如内存页回收、磁盘缓存刷新的触发周期异常，或某些内核模块的周期性调度
• 第三方监控工具：比如Datadog Agent的自定义检查项，若配置为5分钟周期，可能因采集逻辑异常导致资源占用，甚至被误标记为Stolen CPU

3. 线程池耗尽的连锁反应 #

Stolen CPU会导致应用线程的执行被阻塞、超时，线程无法及时释放回线程池，进而引发线程池逐步耗尽。这不是线程池本身的配置问题，而是CPU资源被抢占后的连锁结果。

验证与解决步骤 #

• 确认宿主机层面问题：通过AWS CloudWatch查看实例的CPUStolen指标，同时对比同可用区其他实例的Stolen CPU数据，若只有该实例异常，大概率是宿主机资源竞争
• 抓取周期进程数据：使用pidstat 300 2（每5分钟采集一次，持续两次），记录进程CPU使用率变化，定位是否有进程在峰值时段异常占用资源；同时用systemctl list-timers、cat /etc/crontab排查所有定时任务
• 切换实例类型测试：临时将该实例升级为t3.medium（t3的CPU Credits机制更灵活，且宿主机资源调度策略不同），观察Stolen CPU峰值是否消失
• 检查监控代理配置：核对Datadog Agent和CloudWatch Agent的采集周期，确认是否存在5分钟的自定义检查项，尝试临时禁用非必要的监控任务，验证问题是否缓解

内容的提问来源于stack exchange，提问作者Craig Edwards