识别进程瓶颈需深入内核态，关注系统调用、i/o等待与内存分配；高%us反映用户态计算密集，高%sy表明内核交互失当，高%wa提示磁盘或网络阻塞；优先用perf trace或ebpf替代strace，结合/proc/$pid/stack、vmstat及smaps分析上下文切换与缺页；不同语言需针对性归因：python看gil与i/o、bash查fork频率、node.js检事件循环阻塞。
识别进程执行瓶颈，不能只看用户态脚本表面逻辑，必须顺藤摸瓜，一路追踪到内核态的真实开销点。很多看似“慢”的脚本，真正卡住的地方往往不是代码本身，而是它触发的系统调用、内存分配行为或I/O等待状态。
看懂CPU时间花在哪
高CPU使用率不等于程序写得差，要拆开看：
- 用户态（%us）高：说明脚本自身计算密集，比如Python里大量循环、正则匹配、JSON解析——可考虑用C扩展或改用更高效算法
- 内核态（%sy）高：进程频繁陷入内核，典型如反复open/read/close小文件、短连接HTTP请求、大量fork/exec——这是脚本与内核交互失当的信号
- iowait（%wa）高：脚本没占CPU，但卡在磁盘或网络响应上，比如同步写日志、阻塞式数据库查询、未设超时的DNS解析
抓系统调用，别只靠strace
strace能看调用序列，但生产环境禁用——它用ptrace挂起进程，干扰真实行为。替代方案有：
- 用perf trace -e 'syscalls:sys_enter_*' -p $PID轻量捕获，开销低且支持过滤
- 对关键路径加eBPF kprobe，例如监控read/write返回值和耗时，定位慢I/O源头
- 检查/proc/$PID/stack，看线程当前是否停在D状态（不可中断睡眠），这说明卡在内核驱动或锁竞争中
查内存与上下文切换异常
脚本启动快但运行越来越慢？可能不是算法问题，而是资源压力累积：
- 用vmstat 1观察cs（上下文切换）是否突增：每秒数万次切换，说明进程频繁被抢占或阻塞唤醒
- 看/proc/$PID/status里的voluntary_ctxt_switches和nonvoluntary_ctxt_switches：前者高说明主动让出CPU（如sleep、wait），后者高说明被强制调度（如CPU争抢、高负载）
- 检查/proc/$PID/smaps中的MMU page faults：majflt（主缺页）多，说明频繁读取未缓存文件或mmap大文件未预热
结合脚本语言特性做归因
不同脚本语言暴露瓶颈的方式不同：
- Python：关注GIL释放时机，用strace -e trace=epoll_wait,recvfrom,write看是否卡在I/O而非CPU
- Bash：大量管道或子shell会触发高频fork，用pidstat -w 1观察cswch/s（每秒上下文切换）
- Node.js：事件循环阻塞常见于同步FS操作或长耗时JS函数，用perf record -e syscalls:sys_enter_write确认是否真在写磁盘
