服务器CPU占用过高怎么解决

# 1) 看负载与 CPU 概览：如果 load average 远超核数，说明已严重排队
uptime
nproc                      # 逻辑核数，与 load 对比

# 2) 看是哪一类占用：us 高=应用计算，sy 高=内核/系统调用，wa 高=等磁盘，si 高=网络软中断
top -bn1 | head -12

# 3) 找出吃 CPU 的进程 TOP10
ps aux --sort=-%cpu | head -11

# 保存现场：进程快照 + 每核使用率 + 负载，全部落盘
mkdir -p /tmp/cpu-incident-$(date +%Y%m%d-%H%M%S)
cd /tmp/cpu-incident-$(date +%Y%m%d-%H%M%S)
ps aux --sort=-%cpu > ps-snapshot.txt
top -bn3 -d 1 > top-snapshot.txt
mpstat -P ALL 1 5 > mpstat.txt
uptime > uptime.txt

# 用 systemd 对单个服务限 CPU（例：限制 nginx 最多用 50% 单核）
systemctl set-property nginx.service CPUQuota=50%
systemctl show nginx.service | grep CPUQuota

# 临时用 cpulimit 压制某个已失控的进程（不改配置，立即生效）
cpulimit -p 12345 -l 30 &      # 限制该进程 CPU 上限 30%

# 给低优先级后台任务降调度优先级，避免抢占在线业务
renice +19 -p 12345

# 封禁异常来源 IP（先看访问来源，确认后再封）
tail -n 2000 /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head -20
iptables -I INPUT -s 203.0.113.55 -j DROP

# 重启单个服务而不是整机（保住其它进程现场）
systemctl restart myapp.service

# 在 http{} 中定义限流区：按来源 IP 限制，单 IP 每秒 10 个请求
limit_req_zone $binary_remote_addr zone=perip:10m rate=10r/s;

server {
    location / {
        limit_req zone=perip burst=20 nodelay;
        limit_req_status 429;
        proxy_pass http://backend;
    }
}

# 每 1 秒采样一次，持续观察哪个进程的 CPU 在涨
pidstat -u 1

# 展开某个进程内部的所有线程（LWP/TID 列即线程 ID）
top -Hp 12345
ps -Lp 12345 -o pid,tid,pcpu,stat,comm --sort=-pcpu | head -15

PID=12345

# 1) 找出该进程内 CPU 最高的线程 TID（十进制）
top -Hp $PID -bn1 | head -15

# 2) 把 TID 转成十六进制（jstack 里的 nid 是十六进制，必须带 0x 前缀）
printf '%x\n' 12350        # 例如输出 303e，则 jstack 中搜 nid=0x303e

# 3) 连续抓 3 次线程栈，间隔 5 秒（一次抓栈说服力不足）
for i in 1 2 3; do
  jstack -l $PID > /tmp/jstack-$i.txt
  sleep 5
done

# 4) 在工作目录下搜索该线程，直接看它停在哪个方法
grep -A 25 'nid=0x303e' /tmp/jstack-1.txt

# 顺带确认是不是 GC 把 CPU 吃光了
jstat -gcutil 12345 1000 10
# 若 FGC（Full GC 次数）持续上涨、FGCT 占比高，问题本质在内存而非 CPU

# 实时看整机热点函数（类似 top，但按函数粒度）
perf top

# 只看某个进程
perf top -p 12345

# 采样 30 秒并生成报告（带调用链，-F 99 是常用采样频率）
perf record -F 99 -p 12345 -g -- sleep 30
perf report --stdio | head -60

# 生成火焰图（需先安装 FlameGraph 工具）
perf script > out.perf
stackcollapse-perf.pl out.perf > out.folded
flamegraph.pl out.folded > cpu.svg

# 1) 看 CPU 占用最高的进程，注意进程名伪装（如 kworker、systemd-daemon、nginxs）
ps aux --sort=-%cpu | head -10

# 2) 查该进程的可执行文件真实路径（/proc/PID/exe 会显示被删除的原始路径）
ls -l /proc/12345/exe
ls -l /proc/12345/cwd

# 3) 查外连：看是否连接矿池
ss -antp | grep 12345
lsof -p 12345 | grep -i established

# 4) 查持久化：定时任务、systemd 单元、启动脚本、SSH 公钥
crontab -l; ls -la /etc/cron.d/ /var/spool/cron/crontabs/
systemctl list-unit-files --state=enabled | egrep -i 'suspect|update|network'
cat /root/.ssh/authorized_keys

【故障复盘模板】
1. 影响：时间段 / 影响接口 / 受损请求比例 / 持续时间
2. 时间线：
   - HH:MM 监控告警触发（当时告警的是哪个指标）
   - HH:MM 人工介入
   - HH:MM 执行止血动作 X
   - HH:MM 业务恢复
3. 直接原因：哪个进程 / 哪个线程 / 哪段代码
4. 根因：为什么这段代码会在此时出问题（触发条件是什么）
5. 为什么没提前发现：监控缺失了什么指标？压测为什么没覆盖？
6. 改进项（每项要有负责人和截止日期）：
   - 代码修复
   - 补充监控告警（如 CPU > 85% 持续 5 分钟）
   - 增加防护（限流 / 超时 / 熔断）
   - 预案文档化