监控大数据集群资源开销应聚焦计算进程（如Spark executor、Flink TaskManager），用pgrep提取PID后通过pidstat -p PID -urwd 2细粒度采集CPU、内存、I/O等指标，结合瓶颈特征与调度日志联动分析定位问题。
监控大数据计算集群的资源开销，关键不是看整机负载，而是精准锁定每个计算任务对应进程（如 Spark executor、Flink taskmanager、Hadoop YARN container 进程）的真实消耗。pidstat 正适合这个场景——它能按 PID 细粒度采集 CPU、内存、I/O、上下文切换等指标，且支持脚本化批量采集，不干扰集群运行。
聚焦核心计算进程，避免被无关服务干扰
大数据集群中真正吃资源的是计算进程，不是 zk、namenode 或 journalnode 这类协调/元数据服务。先用 pgrep 精准提取目标进程 PID：
- 查所有 Spark executor：pgrep -f 'org.apache.spark.executor'
- 查 Flink TaskManager：pgrep -f 'TaskManagerRunner'
- 查 YARN Container（含 Java 主类）：pgrep -f 'YarnChild|ContainerLaunch'
拿到 PID 后直接喂给 pidstat，例如：
pidstat -p "$(pgrep -f 'TaskManagerRunner')" -urwd 2
这条命令每 2 秒输出一次这些进程的 CPU、内存、I/O 和上下文切换，字段齐全，便于横向比对各节点任务负载是否均衡。
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
分维度识别典型瓶颈模式
不同资源异常会呈现不同组合特征，结合 pidstat 输出快速判断：
- CPU 高但 %iowait 低、majflt/s ≈ 0 → 纯计算密集型（如宽表 Join、UDF 耗时），需检查代码逻辑或分配更多 vCPU
- %iowait > 30% 且 kB_rd/s 持续高位 → 数据本地性差或磁盘吞吐不足，关注 HDFS 读取路径或本地 SSD 健康度
- RSS 稳步上涨 + majflt/s 突增 → 物理内存不足，触发频繁 swap 或 OOM 风险，需调低 executor memory 或增加节点内存
- nvcswch/s > 5000/s 且 %sys 偏高 → 线程争抢严重（如共享连接池、锁粒度粗），配合 -t 查看具体线程栈
线程级下钻，定位热点线程
单个 executor 或 taskmanager 往往是多线程模型。加 -t 参数展开线程视图，可发现隐藏热点：
- 执行：pidstat -p 12345 -t -u 1（假设 12345 是某个 executor PID）
- 观察 TID 列，找 %usr 最高的线程；再用 ps -T -p 12345 查该 TID 对应的线程名（如 "shuffle-server" 或 "metrics-reporter"）
- 若多个 TID %usr 接近且稳定在 100%，说明是并行计算正常；若某 TID 波动剧烈或长期 99%+，可能卡在 GC 或外部调用
与集群调度信息联动分析
pidstat 数据要结合 YARN UI / Spark History Server 的调度日志才有效：
- 当 pidstat 显示某 executor RSS 突增时，回查 Spark UI 中该 stage 的 input records 和 shuffle read size —— 若后者也激增，说明是数据倾斜导致单 task 处理量爆炸
- 若某节点上所有 container 的 %iowait 都高，但 iostat 显示磁盘 util
- 用 -h 参数让内存单位自动转 MB：pidstat -p "$(pgrep -f 'YarnChild')" -r -h 3，RSS 数值更直观，方便和 yarn.nodemanager.resource.memory-mb 配置比对
