用 time 看清一条命令慢在计算还是在等待

本地脚本忽然变慢时，先别急着改代码。Linux 自带的 time 能把「花在计算上的时间」和「花在等待上的时间」拆开，很多时候一次测量就够决定下一步该看 CPU，还是该看磁盘和网络。

别和 shell 内建的 time 搞混

bash 或 zsh 里直接敲 time，用的是 shell 内建版本，输出只有 real、user、sys 三行，够用但不好单独保存。要更完整的统计，用外部程序：

/usr/bin/time -v python3 job.py

-v 会多出最大驻留内存、缺页次数、上下文切换次数，以及文件系统读写量。若提示找不到命令，在 Debian 或 Ubuntu 上安装名为 time 的软件包即可，它和 shell 内建不是同一个东西。

三行数字怎么读

• real：墙上时钟，从命令开始到结束你实际等待了多久。
• user：进程在用户态消耗的 CPU 时间。
• sys：进程在内核态消耗的 CPU 时间。

如果 real 明显大于 user 与 sys 之和，进程大部分时间在睡觉：等磁盘、等网络、等锁，或者等子进程。如果 user 接近 real，瓶颈多半在纯计算，优先看算法和热点函数。多核程序里 user 可以大于 real，因为多个核上的 CPU 时间会加在一起，这不代表测量错了。

一个容易误判的例子

/usr/bin/time -v curl -fsS -o /dev/null https://example.com

这里 real 往往远大于 user+sys，说明慢在网络往返，而不是 curl 自己算得慢。同样的对比可以套到「扫一大目录再 grep」：如果详细输出里文件系统输入很高、user 不高，就先想缓存和磁盘，而不是先去改正则表达式。

测量时注意这几件事

冷缓存和热缓存差很多。要看稳定耗时，先空跑一次，再记录第二次。time 统计的是它直接拉起的进程及其子进程。前面套了管道时，只包住最后一段会漏掉前面的命令，把整段交给 sh 更稳妥：

/usr/bin/time -v sh -c 'grep -R pattern logs/ | wc -l'

外部 time 的统计写在标准错误。程序自己的报错也会混在同一条流里。更干净的做法是让程序把结果写到文件，标准错误只留给 time，这样事后贴进工单也不会把业务输出和计时搅在一起。

和更重的工具怎么配合

time 适合先回答「慢在哪一类」。确认是 CPU 之后，再考虑 py-spy 或 perf；确认是磁盘之后，再看 iostat。不要一上来就开采样分析器。先用几十秒拿到 real、user、sys，方向会清楚很多。

我习惯把它放在慢任务的第一行：先量化，再决定是改代码、加索引，还是只是网络抖动。排查记录里写上这三行，别人也不用猜你说的「有点慢」到底是两秒还是两分钟。

再补一个容易忽略的点：time 不会告诉你「哪一行慢」，它只划分时间类型。对 Python 脚本，如果 user 很高，下一步用 cProfile 看函数；如果 real 很高而 user 很低，先查是不是在等数据库、对象存储或本机锁。把这个顺序写进团队的排障清单，能少掉很多无效的「再优化一下循环」。