直接答案：服务器 CPU 使用率 100% 时，不要先重启，也不要看到某个进程排第一就立即结束它。正确顺序是：记录时间和业务现象，区分 CPU 真忙还是 IO、锁等待造成的高负载，找到持续占用的进程与线程，再把它和访问日志、发布记录、定时任务、数据库慢请求对应起来。只有确认根因后，才决定限流、回滚版本、停止任务、隔离异常进程或扩容。
重启会让图表暂时下降，却同时清掉最有价值的进程状态和日志时间线。生产服务器如果还有订单、写入任务或数据库，贸然杀进程还可能造成数据不一致。以下命令以常见 Linux 为例；执行停止、重启、清理或改配置前，应先确认服务名、备份和回滚入口。
第一步：确认“100%”到底代表什么
同一个“CPU 高”告警，可能对应完全不同的故障。先连续观察 3～5 分钟，而不是只看一张瞬时截图。
| 指标 | 主要含义 | 常见方向 | 不应直接得出的结论 |
|---|---|---|---|
us 高 |
应用在用户态计算 | PHP、Java、压缩、图片处理、脚本循环 | 不等于一定被攻击 |
sy 高 |
内核态工作多 | 网络包、系统调用、驱动、上下文切换 | 不等于应用代码正常 |
wa 高 |
CPU 在等块设备 IO | 磁盘延迟、数据库刷盘、备份 | 不能靠增加 CPU 解决 |
st 高 |
虚拟机等待宿主机分配 CPU | 共享宿主机争用 | 不能只怪站点程序 |
| Load 高、CPU 不高 | 可运行或不可中断任务积压 | IO、锁、D 状态进程 | Load 不是 CPU 百分比 |
先执行 uptime、top 或 htop，记录负载、us/sy/wa/st、内存和进程列表。再用 pidstat -u -p ALL 1 10 做十次间隔采样。一次采样可能刚好撞上日志轮转或健康检查，连续采样才能区分尖峰和持续故障。
第二步：保存现场证据
建议先建一个事件记录，写明告警开始时间、受影响域名、最近一次发布和正在运行的计划任务，然后保存下列输出：
date -Is与uptime：校准事件时间和负载。top -b -n 1：保存进程快照。ps -eo pid,ppid,user,stat,%cpu,%mem,lstart,cmd --sort=-%cpu：看启动时间、用户和完整命令。pidstat -u -r -d -w 1 10：同时看 CPU、内存、IO 和上下文切换。- Web、应用、数据库和系统日志在同一时间窗口的记录。
不要把包含密码、令牌、Cookie 或个人信息的完整命令行和日志直接贴到公开群里。需要交给服务商时，应先脱敏，但保留时间、PID、状态码和路径等诊断字段。
第三步：从进程追到线程和请求
如果一个多线程进程持续居首，可用 top -H -p PID 查看线程。Java 可再把线程号转换后与线程栈对应；PHP-FPM 应同时看慢日志和各进程池；MySQL 应检查正在执行的 SQL 和慢查询，而不是直接停止数据库。
Web 站点还要把 CPU 峰值与请求对应：
- 同一分钟 2xx 请求和正常用户增长，可能是真实流量峰值；
- 某个动态 URL、搜索接口或登录接口集中出现，可能是爬虫、CC 或缓存绕过；
- 没有访问量增长却出现压缩、备份、转码进程，通常与计划任务有关；
- 命令路径陌生、从临时目录启动、持续对外连接，才需要按入侵事件处理；
- 发布后立刻升高且回滚后恢复，优先检查新版本循环、重试和缓存失效。
Nginx 访问日志应至少保留时间、请求、状态码、响应字节、耗时、上游耗时和 User-Agent。仅凭一个可伪造的 User-Agent，不能断言请求来自真实搜索引擎或 AI 爬虫。
四类高频根因与处理顺序
正常业务峰值
先确认响应时间和错误率。如果 CPU 高但延迟、5xx 和队列仍在可接受范围，可先观察并扩展监控；若已排队，优先启用已有缓存、增加应用进程或水平扩容。扩容前要确认数据库、带宽和磁盘不是下一处瓶颈。
程序异常或无限重试
先摘除单个异常实例或回滚刚发布版本，再保存日志和栈信息。不要一边修改代码、一边清空日志，否则无法判断是哪项变化起效。回滚后用相同请求重测，并核对业务写入是否完整。
备份、压缩或批处理抢占
降低并发、调整到低峰，并用 nice、ionice 或任务自身的并发参数限制资源。不要简单删除备份任务；应确认最近一次可恢复备份仍然存在。备份策略可参考云服务器数据备份与恢复演练。
攻击或恶意进程
攻击流量应先在 CDN、WAF、负载均衡或防火墙侧限速，避免让每个恶意请求都进入应用。若怀疑挖矿或入侵，应先隔离网络、保留进程和登录证据，再决定清除或重装。DDoS 处置可结合云服务器被 DDoS 攻击应急清单和Linux 云服务器安全加固指南。
临时止损怎样避免二次事故
| 止损动作 | 适用条件 | 风险 | 回滚与验收 |
|---|---|---|---|
| 限制单接口频率 | 请求集中且可识别 | 误伤正常用户 | 小范围规则，观察 4xx、业务成功率 |
| 停止单个工作进程 | 已确认可由守护进程重建 | 丢失正在处理的任务 | 核对队列与重试，逐个恢复 |
| 回滚应用版本 | 峰值与发布强相关 | 数据库变更可能不兼容 | 先看迁移脚本，回滚后做核心流程测试 |
| 临时升配 | 业务真实增长且根因明确 | 掩盖泄漏，增加续费成本 | 升配前后保留同口径指标 |
| 整机重启 | 已无其他恢复手段 | 证据消失、服务同时中断 | 确认自动启动、数据库一致性和监控恢复 |
需要换机或扩容时，可查看美国轻量云和美国弹性云服务器的实时配置；不要仅凭 CPU 核数下单，应同时核对内存、磁盘 IO、带宽和升级方式。
修复后的验收标准
至少完成一次相同流量或可重复压测，并同时满足：CPU 各时间类型恢复到基线；负载队列持续下降；接口延迟和 5xx 回到正常范围；异常进程不再重生；计划任务没有丢失；数据库、订单、表单等关键写入正确。再把本次根因、触发条件和告警阈值记录到运维手册。监控设计可参考云服务器监控告警指南。
常见问题
CPU 偶尔到 100% 一两秒要处理吗？
不一定。短暂尖峰可能是压缩、垃圾回收或缓存重建。重点看持续时间、响应延迟、队列和错误率，而不是单个瞬时值。
top 中一个进程显示 200% 正常吗？
在多核系统中，工具可能按每个逻辑 CPU 计 100%，多线程进程超过 100% 并不自动代表统计错误。要结合总核数和工具显示模式解释。
Load Average 高就是 CPU 不够吗？
不是。Linux 负载还包含等待不可中断资源的任务，磁盘 IO、网络存储或锁等待都可能让 Load 高而 CPU 不高。
直接增加 CPU 能永久解决吗？
只有在工作量真实增加、程序可并行且其他资源有余量时才有效。死循环、恶意请求、IO 等待或内存抖动不会因为盲目加核而消失。
能直接结束排名第一的进程吗？
不能只凭排名判断。先确认它的角色、父进程、当前事务和自动重启方式。数据库、队列和主进程被强杀可能造成更大故障。