用 pidstat -p pid 间隔秒数可实时监控指定进程的cpu、内存、io，如 pidstat -p 1234 1；需确保pid存在且有权限，多进程可用 pgrep 动态获取pid列表。
pidstat 怎么查某个进程的 CPU 和内存占用
直接用 pidstat -p 加进程 PID，就能实时看它每秒的 CPU、内存、IO 情况。比如查 PID 1234：
pidstat -p 1234 1最后那个
1 是采样间隔（秒），不写默认是 1 秒；想看 5 秒一刷就写 5。
常见错误是只输 pidstat -p 1234 不带间隔参数——命令会立刻退出，什么也看不到。另外注意：PID 必须存在且当前用户有权限读取（比如非 root 查 systemd 进程会失败）。
-
-u显 CPU（默认就开，可省略） -
-r显内存（%MEM、VSZ、RSS） -
-d显 IO（rkB/s、wkB/s） - 想同时看 CPU 和内存，就写
pidstat -p 1234 -ur 1
找不到进程 PID 时怎么快速定位并监控
别先去 ps aux | grep xxx 再手动抄 PID，容易抄错或漏掉多实例。用 pgrep 直接拿 PID 列表，再喂给 pidstat：
pidstat -p "$(pgrep -f 'python server.py')" 2
这里 pgrep -f 匹配完整命令行，比只匹配进程名更准；但要注意：如果匹配到多个进程，$(...) 会把它们空格拼成一串传给 -p，而 pidstat 支持一次查多个 PID，没问题。
- 如果
pgrep返回空，说明没找到——检查名字是否大小写敏感、有没有空格或特殊字符 -
pgrep -l可以先确认命中的进程和 PID 对不对 - 某些老版本
pidstat（比如 sysstat -p "123,456"
为什么 pidstat 显示的 %CPU 跟 top 差很多
因为 pidstat 默认统计的是“自上次采样以来”的平均值，而 top 默认是“自进程启动以来”的累计平均（按 P 排序时才切到实时）。更关键的是：如果进程生命周期短于采样间隔（比如 1 秒采样，但进程只活了 200ms），pidstat 可能压根捕获不到它，或者显示为 0.00。
- 想逼近
top的实时感，把间隔缩到0.1：pidstat -p 1234 0.1（但太小会导致输出刷屏、系统负载微升） -
%CPU值是相对于单个 CPU 核心的——100% 表示占满一个核，不是整机；多线程程序跑满 4 核，这里可能显示接近400.00 - 注意单位：内存列里的
VSZ是虚拟内存（KB），RSS是常驻物理内存（KB），别直接比大小
pidstat 输出里 RSS 突然暴涨但进程没报错，可能是什么问题
不是内存泄漏就一定崩，得先排除 mmap 映射、大页分配、或 JVM 类加载这类“合法但吃内存”的行为。RSS 上涨本身不等于有问题，但结合 pidstat -p PID -r -H 1（-H 开启高精度时间戳）看趋势，再对比 /proc/PID/status 里的 MMUPageSize 和 MMUPageSize 字段，能判断是不是用了透明大页（THP）导致 RSS 虚高。
-
pidstat -p PID -r不加-H时，时间戳只精确到秒，看不出突变发生在哪毫秒级时刻 - RSS 持续缓慢上涨 +
/proc/PID/status中Threads数稳定 → 更可能是堆内存增长（如 Java 应用未及时 GC） - RSS 瞬间跳变 +
cat /proc/PID/maps | grep -i mmap发现大片匿名映射 → 往往是程序主动mmap(MAP_ANONYMOUS)分配
真正难排查的是那些 RSS 上涨但 malloc 调用量没变的情况——这时候得看 /proc/PID/smaps 里各内存段的 Anonymous 和 SwapPss，而不是只盯 RSS。
