pgrep 不显示 cpu 占用率，仅输出 pid；需配合 ps（如 ps aux --sort=-%cpu）找高 cpu 进程，再用 pgrep -f/-x/-n 精确筛选对应 pid，最后用 ps 或 top 交互验证。

pgrep 本身不直接显示 CPU 占用率，它只负责按条件查找并输出进程 ID（PID）。要找出高 CPU 消耗的进程，需将 pgrep 与真正能反映资源使用情况的命令（如 ps）配合使用——不是靠 pgrep “查 CPU”，而是用 pgrep **精准定位目标进程**，再让 ps 或其他工具展示其 CPU 数据。

先用 ps 找出高 CPU 进程，再用 pgrep 精确筛选

这是最常用也最可靠的做法。因为 ps 支持按 %cpu 排序，能一眼看到谁在“吃”CPU：

• 运行 ps aux --sort=-%cpu | head -n 11：列出当前 CPU 占用最高的前 10 个进程（含表头）
• 观察输出中的 COMMAND 列，识别出可疑进程名或启动参数（比如 python3 train.py、java -jar server.jar）
• 用 pgrep 验证或提取对应 PID，例如：pgrep -f "train.py" 或 pgrep -u www-data java

用 pgrep 定位后，立刻查它的实时 CPU 使用

当你已知某类进程（如所有 nginx 工作进程、某个 Python 脚本）可能异常，可跳过全量排序，直接聚焦分析：

Zynq Linux Hardware Debug

Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。

下载

• pgrep -f "python.*data.py" | xargs ps -o pid,comm,%cpu,%mem,etime -p：先找匹配进程 PID，再用 ps 查它们的 CPU、内存和运行时长
• ps -o pid,%cpu,comm -p $(pgrep -x nginx)：对精确名为 nginx 的主进程查 CPU（-x 避免匹配到 nginx: worker process）
• 如果只想看最新启动的那个高负载实例：ps -o pid,%cpu,cmd -p $(pgrep -nf "node.*server.js")（-n 表示 newest）

结合 top 或 htop 做交互式确认

pgrep 是批处理友好型工具，但排查瞬时峰值时，动态工具更直观：

• 运行 top，按 P（大写）按 CPU 排序，记下高占用进程的 PID 或 COMMAND
• 按下 o 进入过滤模式，输入 COMMAND=nginx 或 PID=1234 锁定观察
• 此时可用 pgrep -l -f "nginx" 对照验证：是否所有 top 里看到的 nginx 进程都被 pgrep 列出来了？有没有漏掉带参数的子进程？

避免常见误区

别指望 pgrep 自己报出 CPU 百分比——它没这个功能。以下操作无效：

• ❌ pgrep -%cpu nginx（语法错误，pgrep 不支持 %cpu 选项）
• ❌ pgrep --sort=-%cpu nginx（--sort 是 ps 的选项，pgrep 不识别）
• ✅ 正确思路是：用 ps 找“谁最耗 CPU”，用 pgrep 查“这个‘谁’是不是你要管的那个具体进程”