strace -c通过汇总统计各系统调用的次数、总耗时、平均耗时、错误数及占比，适用于诊断程序整体慢（如启动卡顿、批量延迟高），但不反映单次调用耗时；需配合-f、-s、-t、-o等参数避免统计失真，重点关注% time、calls、errors和usecs/call字段定位瓶颈。
strace -c 统计系统调用耗时的原理和适用场景
strace -c 不是实时看单次调用耗时，而是运行结束后汇总统计：每个系统调用被调用了多少次、总耗时（time）、平均耗时（avg）、错误次数（errors）以及该调用占总耗时的百分比（% time）。它适合诊断「整体慢」类问题，比如程序启动卡顿、批量处理延迟高，但无法定位某一次 read 为什么花了 800ms。
strace -c 的典型用法与关键参数组合
直接执行 strace -c ./myapp 往往得不到有用信息——默认字符串截断太短、不跟踪子进程、忽略耗时细节。必须加这些参数：
-
-c：启用统计模式（必需） -
-f：否则子进程（如 fork 出的 worker）的调用完全不计入统计 -
-s 256：避免路径、错误信息被截成"..."，影响错误归因 -
-T：虽然-c汇总时不显示单次耗时，但加上它能让 strace 在运行时更准确地采集时间戳（尤其在高负载机器上） -
-o trace.stat：把统计结果输出到文件，避免终端刷屏干扰
完整命令示例：strace -c -f -s 256 -T -o trace.stat ./myapp --mode=import
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
常见误用导致统计失真
strace -c 的统计值容易被以下操作污染：
- 没加
-f：多线程/多进程程序（如 Python 的 multiprocessing、Go 的 goroutine 启动的子进程）的大部分调用不会出现在统计里，你会看到execve占 95% 时间——其实只是主进程初始化开销，真正干活的子进程被忽略了 - 目标程序本身很快退出（如
strace -c ls /tmp）：内核调度精度限制 + strace 自身启动开销，可能导致brk、mmap等初始化调用显示异常高占比，不代表业务问题 - 用
sudo strace -c跟踪需要特权的程序：权限切换过程引入额外的setuid、capget等调用，拉低真实业务调用的占比，掩盖瓶颈 - 统计期间有大量信号（如
SIGCHLD频繁触发）：strace -c默认统计所有调用，信号处理相关调用（rt_sigreturn、sigaltstack）可能挤占排名，需用-e trace=!signal过滤
怎么看懂 strace -c 输出里的关键字段
运行后生成的 trace.stat 文件末尾会有一张表，重点盯这四列：
-
% time：占比最高的调用，通常是瓶颈入口（如epoll_wait高说明卡在等待 I/O，futex高说明线程争抢严重） -
calls：次数异常高（比如百万级gettimeofday）往往意味着轮询或日志打点失控 -
errors：非零值要立刻查——openat错误多可能是配置路径错，connect错误多可能是服务端不可达 -
usecs/call：平均耗时突然飙升（比如平时 1μs 的write变成 5000μs）说明底层设备或缓存出问题（如磁盘满、NFS hang）
注意：strace -c 不显示调用上下文，看到 futex 耗时高，得配合 strace -p PID -e trace=futex 实时抓几次现场，才能确认是哪个锁、哪段代码在阻塞。
