strace -c 统计的是系统调用在内核态的耗时分布，非CPU占用率或函数调用比例；% time为该系统调用总内核耗时占比，seconds为累计内核时间，usecs/call为平均单次内核耗时，calls为调用次数，errors为错误次数。
strace -c 统计的是系统调用层面的耗时分布，不是 CPU 占用率或函数调用比例；它反映的是进程在内核态停留的时间构成，但不能直接等同于“性能瓶颈”本身。
strace -c 输出里各列含义是什么
执行 strace -c ./myapp 后，程序退出时会在 stderr 打印类似这样的汇总：
% time seconds usecs/call calls errors syscall 42.10 0.004210 4210 1 0 connect 28.57 0.002857 2857 1 0 sendto 14.29 0.001429 1429 1 0 recvfrom 14.29 0.001429 1429 1 0 close 0.75 0.000075 75 1 0 write
注意：% time 是该系统调用总耗时占所有系统调用总耗时的百分比，不是占整个程序运行时间的比例；seconds 是所有该类调用的累计内核态执行时间（不含用户态）；usecs/call 是平均每次调用在内核中停留的微秒数；calls 是调用次数；errors 是返回值为 -1 且 errno 非零的次数。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 这个统计只覆盖被 strace 拦截到的系统调用，不包括信号处理、中断响应、调度延迟等其他内核开销
- 如果程序大量做计算（如解密、排序），
strace -c可能显示所有系统调用占比都很低，但程序仍很慢——这说明瓶颈在用户态，strace 看不到 -
execve出现在第一行很常见，但它耗时高通常只是因为加载动态库、解析 ELF 头等初始化动作，并不意味它该被优化
为什么 -c 统计结果和 top/ps 显示的 CPU 使用率对不上
strace -c 统计的是「进入内核并返回」这段时间，而 top 的 %CPU 是采样周期内进程处于运行态（R）或可中断睡眠态（S）中实际获得 CPU 时间片的加权平均。两者维度不同：
- 一个
read(2)调用可能阻塞 500ms（比如从慢磁盘读），strace -c会记作500000 usecs/call，但top只看到这期间进程大部分时间在等待 I/O，%CPU接近 0 - 一个密集循环反复调用
gettimeofday(2)，strace -c可能显示它占了 60% 时间，但每次只花几微秒，top却显示%CPU很高——这是高频小开销叠加的结果 - 多线程程序默认不被
-c跨线程聚合：主线程的write(2)和工作线程的epoll_wait(2)会被分别统计，除非加-f
如何让 -c 结果更贴近真实问题定位
直接跑 strace -c ./app 容易误判，尤其对短生命周期或 I/O 密集型程序。建议按场景调整：
- 排查启动慢：加
-f跟子进程，再加-e trace=execve,openat,stat,fork缩小范围，避免被rt_sigreturn这类高频信号淹没 - 怀疑网络卡顿：用
strace -c -e trace=connect,sendto,recvfrom,accept4，配合-T看单次耗时，比看百分比更有意义 - 对比两次运行差异：用
strace -c -o before.log ./app和strace -c -o after.log ./app，再用awk '{print $1,$4}' before.log | sort -k2nr提取调用次数排序，观察是否某类调用激增 - 注意 -c 不记录失败原因：
errors列只计数，不告诉你 errno 是什么；想查具体错误得去掉-c，用strace -e trace=openat,open -o log.txt ./app再 grep-1 ENOENT
真正难的不是看懂 strace -c 的数字，而是判断「某个系统调用耗时高，是它本身慢，还是上游已卡住导致它不得不等」——比如 recvfrom 耗时长，可能是网卡丢包，也可能是对方发得太慢，还可能是本进程之前没及时 read 导致 socket buffer 堆积。这时候得结合 -T + -tt 看时间序列，而不是只盯着百分比。
