Nginx CPU高需区分master与worker进程：master高多因配置重载或模块异常，worker高则指向请求处理瓶颈；结合top、perf、strace等工具定位user/sys/wa占比及函数级热点，并排查连接数与异常流量。
直接用 top 或 htop 看 Nginx 的 CPU 占用，关键不是“有没有高”，而是“谁在高、为什么高、高在哪一层”。重点区分 master 进程和 worker 进程的行为差异，再结合系统上下文判断是配置问题、请求压力还是底层资源瓶颈。
确认是哪个 Nginx 进程在耗 CPU
Nginx 有两类进程：master（主控）和 worker（处理请求）。它们的高 CPU 原因完全不同：
- 如果 master 进程 CPU 占用异常高（比如持续 >30%），常见于配置重载频繁、信号处理卡顿、或使用了不兼容模块（如某些第三方动态模块加载失败）；
- 如果 worker 进程 单个或多个 CPU 占用接近 100%，说明实际请求处理环节存在瓶颈，比如正则匹配复杂、gzip 压缩开启但未调优、SSL 握手密集、或 upstream 响应慢导致 worker 长时间阻塞。
操作上，先运行：top -p $(pgrep nginx | tr '\n' ',' | sed 's/,$//')
这样能只监控所有 Nginx 相关进程，避免被其他服务干扰。观察时注意 PID 对应的 CMD 列 —— master 进程命令行含 master process，worker 进程显示为 worker process。
结合 CPU 时间类型判断瓶颈方向
单纯看 %CPU 不够，要关注 user 和 sys 时间占比（top 第三行的 us 和 sy）：
- user 时间高（us > 70%）：说明 CPU 主要在执行 Nginx 自身逻辑，比如处理 rewrite 规则、location 匹配、变量计算、或启用的模块（如 lua、perl）消耗大；
- sys 时间高（sy > 20%）：说明大量时间花在系统调用上，常见于频繁 open/read/write 文件（日志轮转太勤、静态文件没走 sendfile）、accept 新连接过多（SYN 队列溢出）、或 epoll_wait 调用异常；
- 如果 wa（I/O wait）也同步升高，说明 CPU 在等磁盘或网络响应，此时即使 worker CPU 高，本质是 I/O 瓶颈，不是 CPU 真不够用。
聚焦 worker 进程做线程级深挖
一个 worker 是单线程的，但 Linux 下它仍可视为一个进程内的“轻量级调度单元”。若某个 worker 持续满载，可用以下方式定位内部热点：
- 用
top -H -p [worker_pid]查看该 worker 内部的线程状态（虽然 Nginx worker 本身不创建多线程，但部分模块如 ssl、resolver 可能触发内核线程）； - 更有效的是用
perf top -p [worker_pid]（需安装 perf），实时看到函数级 CPU 消耗 —— 比如ngx_http_regex_exec占比高，就说明 rewrite 正则太重；SSL_do_handshake高，说明 TLS 握手开销大；ngx_http_upstream_send_response持续占用，可能 upstream 响应慢且未设 timeout； - 配合
strace -p [worker_pid] -c统计系统调用频次和耗时，能快速发现是否卡在read、write或epoll_wait上。
排除干扰，验证真实负载来源
CPU 高不一定来自正常流量，可能是异常行为：
- 用
netstat -anp | grep :80 | grep ESTABLISHED | wc -l或ss -tn state established '( dport = :80 )' | wc -l查当前活跃连接数，对比worker_connections设置，确认是否连接数已逼近上限； - 检查 access log 最近 1 分钟的请求分布：
tail -n 10000 access.log | awk '{print $1}' | sort | uniq -c | sort -nr | head -10，看是否有单 IP 短时高频访问（爬虫或攻击）； - 临时加一条
limit_req规则，或用deny封掉可疑 IP，观察 CPU 是否回落 —— 若明显下降，说明是流量型问题，而非配置或代码缺陷。
