部署包在服务器上解压慢三分钟，我查了半天发现是文件系统这块拖后腿

上周发版遇到个怪事，同一批部署包（大概 1.2G，里头几十个日志和 jar），在本地 NVMe 盘上解压 40 秒搞定，丢到测试服务器上解压了三分半。一开始我怀疑是 Win解压缩 的锅，毕竟版本不一样，结果换了 7-Zip 命令行也一样慢，那就得往别处找了。

先报环境：

• 本地：Win10 22H2，NVMe，NTFS
• 测试机：CentOS 7.9，机械盘 RAID5，xfs
• 包：1.2G，其中 800M 是个大日志文件，剩下是小文件

排查三步：

1. 看小文件数量。tar -tf 数了一下，一千多个小文件。机械盘上随机写小文件，延迟直接上天，这跟解压软件没关系。

1. 看文件系统挂载参数。mount 一看，xfs 挂载没加 noatime，每次读文件都要更新访问时间，白白多一轮写。加上 noatime 重挂载后，解压时间从 3 分半降到 2 分 50 秒。

1. 看是不是在同一个盘上解压。测试机把包放在 /data（机械盘），解压目标也在 /data，等于一边读一边写同一个盘，磁头来回跑。把包先拷到 /tmp（内存盘 tmpfs），再解压到 /data，时间直接砍到 1 分 40 秒。

结论： 解压速度这东西，软件层面（Win解压缩、7-Zip）在本地 SSD 上差距也就几秒，到了机械盘上，瓶颈根本不在解压算法，在 I/O 调度。小文件多的时候尤其明显，一个 1.2G 的包能给你拖出三倍的差距。

给同样场景的兄弟几个土办法：

• 打包前尽量把小文件合并，日志按天归档成一个文件，别几千个碎文件
• 服务器上解压，源包放 tmpfs 或者 SSD 分区
• 挂载参数加 noatime，顺手的事
• 机械盘上真要频繁解压，考虑换一块 SSD 当缓存盘

最后问一句：你们发版的时候，部署包是直接在目标机解压，还是先传到本地缓存目录再分发？我这边现在纠结要不要在每台机器上搞个 tmpfs 的中转目录，但又怕内存不够用。