监控高并发Web服务需持续、精准、多维度捕捉瞬时波动和资源瓶颈，pidstat是top的深度搭档，可按进程/线程级分析CPU、内存、IO等指标，并结合pgrep动态获取PID、避免权限与采样间隔陷阱。
监控高并发 Web 服务，关键不是“看一眼”，而是持续、精准、多维度地捕捉瞬时波动和资源瓶颈。pidstat 不是 top 的替代品，而是它的深度搭档——它能告诉你某个 Nginx worker 或 Java 应用线程在每一秒里到底干了什么。
先锁定目标进程，别靠肉眼找
Web 服务通常有多个工作进程（如 Nginx 多 worker、Tomcat 多线程、Gunicorn 多 worker），手动 ps + grep 容易漏掉或抄错 PID。直接用 pgrep 动态获取更可靠：
- 查所有匹配 nginx 的主进程和 worker：
pgrep -f "nginx: worker"或pgrep -P $(pgrep nginx) - 查 Java Web 进程（如 Spring Boot）：
pgrep -f "java.*spring-boot"，加-l先确认命令行是否准确 - 把结果直接喂给 pidstat：
pidstat -p "$(pgrep -f 'nginx: worker')" -ur -d 0.5—— 同时看 CPU、内存、IO，每 0.5 秒采样一次
重点盯住这三类指标，而不是只看 %CPU
高并发下，%CPU 高只是表象，真正卡点常藏在别处：
linux-sysadmin
下载
Linux系统管理专家，覆盖12大模块：用户权限、SSH、存储、网络、systemd、防火墙、日志监控、备份恢复、TLS证书、Ansible、容器、IaC。提供配置、验证、加固、监控、备份、自动化、故障排查、回滚闭环。关键词：useradd、sudo、sshd_config、chmod、SEL...
-
CPU 细分：关注
%usr（业务逻辑）和%system（系统调用）。如果 %system 明显偏高（比如 >30%），可能是频繁 open/close 文件、大量 socket 操作或锁竞争 -
内存压力信号：看
majflt/s（主缺页中断）。值 > 0 表示进程正在频繁从磁盘读取页面——可能是堆内存不足触发 GC 回收，也可能是 mmap 加载大文件；RSS 突增但 VSZ 变化不大，大概率是堆分配或缓存膨胀 -
I/O 等待真相：
%wait字段不直观，改看rKB/s和wKB/s是否异常高，再结合pidstat -w查nvcswch/s（非自愿上下文切换）。如果这个值飙升，说明进程在等 CPU 调度，本质是 CPU 竞争激烈，而非 I/O 慢
按线程级拆解，定位热点函数或连接处理瓶颈
单个进程内可能有几十个线程并行处理请求，全局平均值会掩盖问题。加 -t 参数看线程粒度：
-
pidstat -p $(pgrep -f "java.*api") -t -u 1—— 列出该 Java 进程所有线程的 CPU 占用 - 重点关注名字含
http-nio、worker、grpc或自定义线程池名的线程。如果某线程 %CPU 长期 > 90%，基本就是热点所在 - 配合
jstack PID | grep 'RUNNABLE' -A 5（Java）或perf top -p PID（通用），可进一步定位到具体方法或系统调用
避免常见陷阱，让数据真正可用
几个容易踩的坑，直接影响判断准确性：
- 采样间隔别设成 1 秒就完事：高并发场景下，1 秒太长，可能错过尖峰。建议从 0.2 或 0.5 秒起步，观察输出节奏和系统负载，再平衡精度与开销
- 别忽略权限问题：普通用户无法读取其他用户启动的 Web 进程（如 root 启动的 Nginx 主进程）。用
sudo pidstat或确保以相同用户身份运行 - %CPU 是单核占比：4 核机器上看到 380.00，说明它几乎占满全部 CPU；若只显示 99.00，可能只是绑定了一个核，要检查进程亲和性（taskset）或容器 CPU limit
- 输出默认不含时间戳：加
-h（人类可读单位）和-T ALL（包含线程+进程汇总）能让报告更易解读
实际排查时，往往要组合使用：先用 pidstat -u 找出 CPU 最高的 PID，再用 pidstat -p PID -t -u 0.2 看线程分布，接着用 pidstat -p PID -r -d 0.2 对照内存和 IO 变化趋势。不复杂但容易忽略细节。
