pidstat监控容器性能需先获取宿主机PID，再结合权限、参数组合及命名空间特性分析CPU、内存、IO等指标。推荐用docker inspect获取PID，注意cgroups限制与短生命周期进程采样精度。
在容器化环境中用 pidstat 监控应用性能，核心是找准容器内主进程的 PID，并注意命名空间隔离带来的权限和可见性限制。它不能直接监控容器名或镜像，而是监控 Linux 进程——只要容器进程在宿主机上可见、且你有权限读取，pidstat 就能用。
先确认容器主进程 PID
容器本质是普通进程，主进程通常是应用本身（如 Java、Python、Node.js），不是容器运行时（如 dockerd 或 containerd）。别用 docker ps 看容器 ID 后手动查，容易错配或漏掉多实例：
- 用
docker inspect -f '{{.State.Pid}}' 容器名或ID直接拿到宿主机上的真实 PID（推荐，准确、无歧义） - 或用
pgrep -f 'java.*spring-boot'类似方式匹配命令行（适合调试阶段，但要注意匹配精度，避免误抓日志进程等） - 若容器以非 root 用户启动，且你用普通用户执行 pidstat，可能因权限不足看不到其内存/IO 细节；此时需 sudo 或切换到对应用户（
sudo -u $USER pidstat -p $PID ...）
按需组合参数看关键指标
容器应用常见瓶颈集中在 CPU、内存、IO 和上下文切换，pidstat 可一次指定多个维度：
- CPU + 内存：
pidstat -p $PID -ur 1→ 查 %CPU、%MEM、RSS（物理内存）、VSZ（虚拟内存） - CPU + IO：
pidstat -p $PID -ud 1→ 查 kB_rd/s、kB_wr/s，判断是否磁盘写入拖慢响应 - 上下文切换异常高？加
-w：pidstat -p $PID -uw 0.5→ 看 cswch/s（总切换）和 nvcswch/s（自愿放弃 CPU 次数），飙高常意味着锁竞争或频繁阻塞 - 想看线程级分布？加
-t：pidstat -p $PID -ut 1→ 输出中会显示每个线程的 CPU 占用，帮助识别单线程瓶颈或线程泄漏
注意容器场景下的特殊表现
pidstat 的数值含义在容器里不变，但解读需结合 cgroups 限制和命名空间特性：
-
%CPU 是相对于单核的：一个 Java 应用跑满 4 核，pidstat 显示接近 400.00；若容器设置了
--cpus=2，它实际不可能超 200.00，超过说明调度受限或统计抖动 -
RSS 上涨不等于泄漏：JVM 堆外内存、Golang 的 mmap 缓冲、Python 的大对象都可能导致 RSS 突增；配合
cat /proc/$PID/status | grep -E "VmRSS|MMUPageSize"看是否启用透明大页（THP），避免误判 -
短生命周期进程难捕获：K8s 中 Job 或 InitContainer 可能只运行几百毫秒；pidstat 默认 1 秒采样易错过，可压到
0.1（pidstat -p $PID 0.1），但别长期使用，会增加轻微负载 -
无法跨命名空间自动映射：pidstat 运行在宿主机，看到的是 host PID namespace 下的 PID；容器内
ps aux显示的 PID 是容器自己的 namespace 视图，二者不同，切勿混用
实用小技巧
把动态获取 PID 和监控串起来，适合写进部署后检查脚本：
- 查某个容器里 Java 进程并每秒看 CPU+内存：
pidstat -p "$(docker inspect -f '{{.State.Pid}}' myapp)" -ur 1 - 同时监控多个容器主进程（如 sidecar 场景）：
pidstat -p "$(docker inspect -f '{{.State.Pid}}' app) $(docker inspect -f '{{.State.Pid}}' nginx)" -ud 2 - 加时间戳便于事后分析：
pidstat -p $PID -urH 1 | awk '{print strftime("%H:%M:%S"), $0}'
