@Exp #10 IO 状态得 SSH 进去用命令看，iostat 、sar 之类的
不过如果你确定当时只有 1MB/s 左右，那这个速率可以肯定是包含大量随机访问了。

我详细回看了一下以前的文章收藏，感觉可能是你的使用情景触碰到了文件系统的瓶颈（也不知道你用的啥文件系统，截图里没看到。ext4 ？ btrfs ？），贴一下看对你有没有帮助吧：

www[.]zhihu[.]com/question/22555963/answer/1671045642
"""
单个 1G 的文件，在现代文件系统里，可能至多需要十次不到的寻道就能全部读取；而 1024 个 1M 的细小文件呢，那就相当于 FAT 时代、存在一千个文件碎片的单个大文件——起码多了一千次寻道呢，怎么可能不慢。

事实上，这样算还是算少了。因为磁盘驱动必须先读取文件分配表，然后才能拿到“指针”、才能去按照“指针”指示寻找对应的扇区；那么对 1G 的大文件，文件分配表寻道一次，扇区寻道一次，差不多就够了；而对 1M 的一堆小文件呢，文件分配表寻道 1024 次，每个文件的首扇区又要寻道 1024 ，实际多了两千多次寻道。

按每次寻道需要 15ms 算，额外就需要 15X2000=30000 毫秒，也就是 30 秒时间；而现在的硬盘在顺序读写时平均读写速率可以飙到 170M/s 以上；哪怕按 100M/s 算，1G 的文件 10 秒也能传完了；结果寻道愣是多寻了 30 秒——慢了足足 3 倍！

而且，这里仅仅算了读取；写入时，小文件也需要先写文件分配表后写内容，这显然又是一堆寻道……不过这个场景过于复杂（比如同个磁盘不同分区拷贝、不同磁盘之间拷贝等等，细节各有不同），就不深入分析了。
"""


如果要我来猜的话，就是系统批量写入的时候，是一个顺序，记作 A ，读取的时候，操作系统提交给文件系统的是另外一个顺序，记作 B ，B 相较 A 已经不同了，而文件系统将 B 优化后的读取顺序，记作 C 。C 虽然已经按照磁盘文件实际位置做了大量优化，但其相对于 A ，还是有大量乱序，导致了随机 IO 占比过高