日志包解压到一半卡死，我用iostat盯了半小时才发现是磁盘在拖后腿

上周排查线上问题，运维甩过来一个18G的日志压缩包，让我自己解。我照惯例双击用Win解压缩解，进度条走到73%就不动了，任务管理器一看CPU才15%，心想这软件是不是卡了。

换7-Zip命令行重来一遍，7z x logs.7z -o./out -mmt=8，结果一样，也是那个位置慢得像蜗牛。这时候我才意识到问题不在软件。

上数据，别猜：

• 机器：Win11 23H2，i5-12400，16G内存，SATA SSD（不是NVMe）
• 包体：18.2G，约42万个日志小文件，平均单文件40K左右
• Win解压缩：全程约11分20秒，CPU峰值38%
• 7-Zip（-mmt=8）：约10分50秒，CPU峰值41%
• 解压过程中iostat看磁盘：util长期95%以上，队列深度一直在8-12

结论很直白：瓶颈在磁盘IO，不在CPU，也不在解压算法。 42万个小文件，每个都要open/write/close，SATA SSD扛不住这种随机小写入。软件本身那点差距（30秒）在总耗时面前可以忽略。

顺便说个踩坑细节：Win解压缩默认会把解压出来的文件放在同一个目录下平铺，42万个文件挤一个文件夹，资源管理器打开直接转圈半分钟。7-Zip我加了-spe保留目录结构，情况好很多。这一点普通用户基本感知不到，但对我们这种天天处理日志包的人挺要命。

我现在的做法：

1. 超过10G的日志包，先看里面文件数，7z l列一下，小文件多就预留时间
2. 解压目标目录放NVMe盘，别图省事丢机械盘或者系统盘
3. 批量处理用7-Zip命令行，脚本能串起来；临时看个包就Win解压缩双击，快且省事
4. 小文件特别多的包，考虑先tar打成单文件再压，能省掉大量元数据开销

所以我的判断没变：Win解压缩解压速度确实快，适合普通用户日常用；但命令行这块还是7-Zip的天下，脚本化场景没法替代。

想问问大伙：你们处理这种几十万小文件的日志包，有没有试过先打包成tar再传输压缩？我担心打包本身也要花时间，一直没认真测，有没有实测过的兄弟说说值不值？