执行相同Bash代码时的耗时差异问题排查

这是个很接地气的问题——我之前处理批量文件哈希计算时也碰到过一模一样的情况，第一次跑慢得要死，第二次直接起飞。下面是几个实际生产环境里最常见的原因：

• 操作系统文件系统缓存是头号元凶
  第一次执行时，所有图片都存在磁盘（不管是HDD还是SSD）上，程序需要从磁盘读取每一个文件的内容来计算MD5，这个过程受限于磁盘的IO速度，耗时很长。但执行完一次后，操作系统会把刚读过的文件内容暂存到内存缓存里（也就是页缓存），第二次执行时，程序直接从内存读取数据，速度比磁盘快几个数量级。
  你可以验证一下：执行前用echo 3 > /proc/sys/vm/drop_caches（Linux下需要root权限）清空缓存，再跑两次，第一次的耗时会回到初始状态，第二次又会变快。

• 磁盘自身的硬件缓存加成
  除了系统层面的缓存，你的硬盘（尤其是SSD）本身也有内置缓存。第一次读取图片后，热门数据会被存在硬盘的缓存芯片里，后续访问这些文件时，硬盘直接从缓存返回数据，不用再去读写闪存/磁盘盘面，速度自然提升。机械硬盘的话，第一次还需要花费时间寻道到文件所在的扇区，第二次因为缓存的存在，寻道时间大大减少。

• CPU动态调频的影响
  现在的CPU大多支持动态节能和睿频模式。第一次执行代码时，CPU可能处于低功耗的低频状态，需要一点时间“唤醒”到高频睿频状态；而第二次执行时，CPU已经处于高性能模式，处理哈希计算的速度自然更快。你可以在执行前后用cpufreq-info（Linux）或者任务管理器（Windows）查看CPU频率变化，就能发现这个差异。

• 后台进程的资源抢占
  第一次执行时，可能刚好有后台进程在抢资源——比如系统自动更新、杀毒软件扫描、备份任务等等，这些进程会占用磁盘IO、CPU或者内存，导致你的MD5计算代码变慢。第二次执行时，这些后台任务刚好结束了，资源都空出来，性能自然就上去了。可以用htop或者top命令观察第一次执行时的系统资源占用情况，就能找到线索。

• 脚本/解释器的启动缓存（如果用脚本语言的话）
  要是你用的是Python、Shell这类脚本语言写的代码，第一次执行时需要加载解释器、导入依赖模块，这些都需要时间。后续执行时，操作系统可能已经把解释器的二进制文件和模块缓存到内存里，启动速度会快一些，整体耗时也就减少了。不过这个影响通常比前面几个小很多。

总的来说，文件系统缓存是最常见的原因，几乎每次碰到这种“第一次慢后续快”的情况，都是它在搞鬼。

内容的提问来源于stack exchange，提问作者Miguel Isla