返回列表

亚马逊云长期稳定号 EC2 CPU 使用率飙到 100% 卡死？从定位进程到性能调优的全套思路

亚马逊aws / 2026-08-04 14:19:32

EC2 CPU 使用率飙到 100% 卡死？先别急着重启

在 AWS EC2 上遇到 CPU 使用率突然打满，很多人第一反应是重启实例。实际处理里，这一步往往只能把现场清掉，不能解决根因。更麻烦的是，有些环境连“临时加机器”都做不到，卡在账号认证、支付方式、风控审核或资源配额上，最后只能边掉流量边排障。

所以这类问题要按顺序处理：先定位是谁吃满 CPU，再判断是业务峰值、代码问题、实例规格不匹配，还是账号侧限制让你没法扩容。

先判断：是真满载，还是被别的瓶颈拖成“像满载”

常见的几种情况

单个进程吃满 CPU：比如 Java 进程、Python worker、压缩任务、日志处理脚本。
多个进程同时上来：常见于定时任务集中触发、队列积压后批量消费。
CPU 其实没那么忙，但系统很卡：磁盘 I/O 高、iowait 高、内存换页严重，表面看像 CPU 问题。
T 系列实例 CPU credit 用完：常见于 t3/t4g 一类实例，平时看着够用，流量一上来就顶满。
异常请求或攻击流量：接口被刷、爬虫打爆、登录暴力尝试，都会把应用层打到高 CPU。

最先看的不是监控图，而是进程

先用 top 或 htop 看是不是某个 PID 长时间占高 CPU。
再用 ps -eo pid,ppid,cmd,%cpu --sort=-%cpu | head 锁定进程名。
用 pidstat -u 1 5 看是不是持续升高，还是短时尖峰。
结合 uptime、vmstat 1 5、iostat -x 1 5 判断是不是 I/O 或内存拖慢系统。
如果是生产环境，再看 journalctl -xe、应用日志、CloudWatch 指标，确认是不是某个接口或任务在反复报错重试。

经验上，CPU 100% 不可怕，最怕的是只看总览图不看进程。很多“卡死”最后都能落到一个具体任务、一个热点接口，或者一个失控的后台作业上。

从进程定位到根因：实际排查时常见的 6 类问题

现象	常见进程/场景	排查重点	容易忽略的点
CPU 持续 100%，请求超时	Java / Node / Python 服务	线程数、GC、死循环、同步锁竞争	日志里反复重试，会把问题放大
高峰期突然拉满	API、Web 服务	入口流量、Nginx 转发、应用层限流	缓存失效后，数据库压力一起上来
夜间定时打满	cron、备份、压缩、报表任务	任务是否重叠、是否没做错峰	一个任务没结束，下一个又启动
数据库 CPU 高	MySQL / PostgreSQL	慢查询、缺索引、锁等待、连接数	应用重试会把锁竞争进一步放大
重启后短暂恢复，很快又满	配置错误、热点代码、流量没降	谁在持续触发同一个瓶颈	只重启不止损，问题会反复出现
莫名其妙吃 CPU	异常进程、挖矿、被入侵	陌生进程、异常外联、计划任务	先隔离，再分析，别直接在原机上反复试

处理顺序：先止血，再修复，最后优化

1. 先止血，不要先追求彻底修好

把入口流量先降下来：临时限流、关闭非核心接口、切到只读模式。
停掉明显可疑的定时任务、批处理任务、重复消费任务。
如果是单实例扛不住，优先做横向扩容，不要只盯着当前机器硬撑。

2. 再判断是“代码问题”还是“规格不够”

如果某个接口在固定流量下就会把 CPU 拉满，通常不是单纯加机器能解决的，要看代码路径是否过重、有没有重复计算、序列化是否过慢、数据库调用是否过多。相反，如果平时稳定，峰值一来就顶满，往往是实例规格偏小或者没有做伸缩。

3. 最后才是调优

应用层：减少无效循环、批量处理、缓存热点数据、降低同步锁竞争。
Java 服务：关注 GC 时间、堆大小、线程池配置，不要让线程数无上限增长。
数据库：补索引、拆慢查询、减少大事务、控制连接数。
Web 层：调整 Nginx 配置、开启合理缓存、限制异常客户端频率。
实例层：如果长期是计算密集型任务，尽量别长期依赖突发型实例，换成更稳定的计算型或通用型规格。

不同业务场景下，怎么选修复方向

场景一：对外 API / 网站

这类场景最怕的是“用户一多，CPU 和数据库一起爆”。处理上先看接口是否有热点、缓存是否失效、是否有某个版本上线后查询次数翻倍。短期内可以先做流量削峰；长期要配合自动伸缩组和负载均衡，避免单台 EC2 顶死。

场景二：任务队列 / 离线批处理

很多团队会把报表、同步、消息补偿、图片处理都放在同一台 EC2 上。平时没事，一到整点就把 CPU 拉满。这个时候要做的是拆任务、分优先级、错峰执行，不要把所有计算都压在业务高峰同时段。

场景三：数据库主机

数据库 CPU 高，通常不是“加一点点机器”就结束了。先查慢查询和锁等待，再看缓存命中率、连接池和 ORM 生成的 SQL。数据库和应用层一起调，效果比单纯升级实例更稳。

场景四：T 系列 EC2

如果你用的是 t3、t4g 这类实例，先看 CPU credit 是否已经接近耗尽。很多人看到监控里 CPU 没有一直爆满，就误以为机器没问题，结果业务一上量就开始卡。对于持续计算型业务，这类实例更适合短峰值，不适合长期高负载。

别忽略账号侧问题：想扩容，先确保能下单、能扣款、能过审

亚马逊云长期稳定号 实战里，CPU 打满之后最怕的不是技术排障，而是你想临时加一台 EC2，却发现账号侧出问题：新账号还没完成实名认证或企业认证，支付方式没通过，账单风控触发了，或者资源配额已经用完。

账号开通与认证：新建 AWS 国际站账号时，实名信息、企业信息、联系人邮箱和手机号要一次填准，后面改资料容易触发复核。
支付方式：常见卡在信用卡验证、账单地址不一致、卡组织限制、额度不足。临时故障时，备用支付方式最好提前准备。
风控审核：新账号短时间开很多实例、频繁切换地域、突然拉高预算，容易触发审核。扩容动作最好和正常业务节奏对齐，不要一口气做太大。
资源限制：EC2 实例数量、vCPU、EIP、Security Group 规则、按区域配额都可能限制扩容。平时就要查 quota，别等故障时才发现申请来不及。

从成本角度看，AWS 不是“充值续费”模式，但账单和预算管理一样关键。很多团队平时只开按需实例，等到CPU持续高负载才开始找人申请预算，最后不是算力不够，而是账单和权限先卡住了。

你现在遇到的情况	优先动作	是否需要先处理账号/支付
某个进程单独打满 CPU	定位进程、看日志、停掉异常任务	通常不需要
高峰期整体扛不住	扩容、自动伸缩、拆热点	如果要临时加实例，需要确认额度和支付可用
新账号还没稳定下来	先完成认证、支付方式绑定、预算告警	需要，先把账号侧打通
频繁创建资源被拦截	检查风控、配额、地域限制	需要，先过审核再扩容

常见错误：很多团队不是不会排障，而是顺序错了

只看 CPU 总览，不看具体 PID。
亚马逊云长期稳定号 一卡就重启，结果没有保留日志和现场。
把磁盘 I/O 高误判成 CPU 问题。
同一台机器上同时跑业务、备份、报表、同步任务。
故障时才去补账号认证、支付方式和配额申请。
长期使用不适合负载类型的实例规格，比如持续高压还留在突发型实例上。

FAQ

亚马逊云长期稳定号 Q1：EC2 CPU 100% 但 load 不是特别高，怎么理解？

先看是不是单核打满、线程竞争或短时尖峰。CPU 总利用率高不等于系统整体健康，很多时候线程池、锁、GC 或 I/O 才是根因。

亚马逊云长期稳定号 Q2：重启后恢复正常，说明问题解决了吗？

通常没有。重启只是清掉了进程状态，真正的问题可能还在：代码热点、任务堆积、数据库慢查询、异常流量，都会在下一次高峰再出现。

Q3：如果我是新开的 AWS 国际站账号，故障时为什么扩容失败？

常见原因是实名认证或企业认证未完成、支付方式验证失败、账单风控触发、区域配额不足。平时把这些先处理好，故障时才有空间做临时扩容。

Q4：什么时候该直接换实例规格，而不是继续调代码？

如果业务本身就是计算密集型，代码已经做过基础优化，且峰值稳定超过当前规格承载能力，继续抠细节收益有限，直接换更合适的实例家族更省时间。

实战里，最有效的处理方式不是“先重启”，而是“先定位、先止血、再调优”。同时把账号、支付、配额和风控准备好，才能在真出问题时完成扩容，而不是被平台侧流程卡住。

最后给一个实用决策顺序

先确认是不是某个进程或任务把 CPU 吃满。
再看是不是 I/O、内存、锁竞争导致假性满载。
如果是业务峰值，先止血并评估扩容。
如果是代码热点，做针对性调优，不要只重启。
如果准备扩容，提前检查 AWS 账号认证、支付方式、风控状态和资源配额。
如果长期高负载，重新评估实例规格和成本控制方式。

这样处理，才能把“EC2 CPU 使用率飙到 100% 卡死”从一个临时故障，变成一次可以复用的排障流程。