strace -c 是定位系统调用级性能瓶颈最轻量有效的工具，可统计调用次数、总耗时、错误数及占比，但仅反映采样期间相对开销，非精确计时，且对高吞吐进程可能失真。
直接用 strace -c -p PID 就能统计，但必须注意：它只反映采样期间的相对开销，不是精确计时器，且对高吞吐进程可能失真。
用 strace -c 获取系统调用耗时汇总
这是最常用、最轻量的方式，适合快速定位“哪个系统调用拖慢了进程”。
-
strace -c -p 1234：附加到运行中的进程，按Ctrl+C中断后输出汇总（含调用次数、总耗时、错误数、占比） -
strace -c ls /tmp：启动新命令并统计全程——注意，ls这类短命进程要快，否则容易漏掉 - 输出中
% time列是关键，值高 ≠ 问题大，但若read或write占比超 80%，大概率是 I/O 瓶颈 - 不加
-f时，子进程调用不会计入父进程统计；若进程会fork出工作子进程（如 nginx worker），必须加-f，否则统计无意义
strace -T 看单次调用耗时，但别信绝对数值
strace -T 在每行末尾显示该次系统调用从进入内核到返回用户态的耗时（单位秒），但它受多种干扰：
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 时间测量本身有开销，
getpid这种微秒级调用显示0.000000是正常的，不代表真为 0 - 若进程被调度抢占、缺页中断、锁竞争，
-T显示的“耗时”实际混入了这些延迟，不是纯内核执行时间 - 高频调用（如循环
write）下输出爆炸，建议配合-e write,read过滤，或重定向到文件再grep -
strace -T -e trace=write -p 1234 2>&1 | head -20是安全的调试组合，避免终端刷屏失控
为什么不用 time 或 pidstat？
它们解决的是不同层级的问题：
-
/usr/bin/time -v给出的是整个进程的user和sys时间，但无法拆解到open、connect这一级别 -
pidstat -u -p 1234 1只能看到 CPU 使用率波动，看不出是卡在epoll_wait还是malloc的 mmap 上 - 真正需要“哪个系统调用耗时最多”时，
strace -c是唯一能直接回答的工具；其他工具只能辅助交叉验证 - 如果
strace -c显示nanosleep占比奇高，说明进程在主动休眠，不是性能问题——这点容易误判
最后提醒：strace 本身会显著拖慢目标进程（尤其高频调用场景），生产环境慎用；统计结果反映的是观测窗口内的行为，不能外推到长期趋势。想持续监控，得换 eBPF 工具如 bpftrace 或 perf，但那是另一套复杂度了。
