4K随机性能等于4K小文件性能吗？多系统图文测评

文章为JEFFXL原创内容，转载请注明出处，欢迎转载

很多人都有一个概念，认为SSD的4K随机性能等同于同尺寸小文件操作性能。首先这里有一个误区，什么是随机访问？随机访问是不同的读写请求造成的访问地址碎片化、乱序化的访问。

连续的小文件访问不一定是随机的，这点从光驱复制大量小文件（比如光盘软件安装）对比从光盘直接运行只读程序（比如各种PE或其他只读方式的应用）差别是巨大的（寻道音和速度几乎不可忍受），连续的小文件复制可以是持续访问，连续寻道，并不需要额外的光头/磁头移动，也不需要等待潜伏期（如果需要，请先了解相关机械寻道原理）。复制连续的小文件产生的压力远小于运行程序时产生的随机寻址压力。

同理随机访问并不等于小文件访问，譬如魔兽世界在资源载入过程和无缝地图产生的即时资源载入过程，这些访问往往都是访问的魔兽世界文件夹内那些容量巨大的材质库，单个文件都是N个G的容量。那么这么大的文件访问操作难道是持续访问？因为材质是分布在这类大文件的不同的位置，而用户在游戏当中的行为完全不可预知，即时读取需要的材质几乎是随机的，就在那些大型资源文件的某个部分当中，访问自然就是随机的了。其实几乎没有什么应用的运行过程产生的IO是持续访问，不管资源文件的大小，是否碎片化，访问一定是随机的。

那么复制连续的大文件就是持续咯？也不全对，机械盘/光盘是面型存储的，寻道访问数据时是线性的，寻址是径向移动磁头摇臂并配合盘片旋转（这叫潜伏期等待）来寻找到他需要的数据。那么如果这个大文件的存储分布是碎片化的（物理分布碎片化，非寻址逻辑碎片化），那么在复制这些文件时就会产生额外的寻道和潜伏期等待（看文件碎片数量的大小，需要的响应时间不同）时间，那么这样的操作对于物理上的寻址访问来说也是接近随机访问的。大家知道机械盘非常不擅长这样的操作，所以这里就产生了随机性能问题。可以看出就算是大型文件的复制粘贴也不一定是持续访问。页面文件（虚拟内存实体文件）也是同理，可能8G的页面文件那么大，但页面文件的访问几乎是纯4K随机访问。

复制粘贴文件，无论大小，不一定是随机也不一定是持续访问，要看文件分布是否是连续的。跑应用时访问大型文件的IO操作不一定是持续访问，要看访问需求的分布。家庭典型应用产生的IO几乎全部为随机访问

综上所述，随机性能并不等于小文件操作能力，有时候小文件性能大于同尺寸随机能力，有时候小文件性能低于随机能力。而往往在大家的应用环境中，小文件操作性能必定低于随机能力，下面将通过不同架构的操作系统复制大量小文件来测试操作系统对文件操作的影响，谈谈小文件性能低下是由什么产生的？（这里谈的连续分布的小文件）

各种产品的随机性能，大家通过浏览本版都有一些认识了，但大家知道不同的操作系统对小文件操作有什么区别吗？下面就从实际的测试来验证这些到底有什么区别（下篇发布，敬请期待）

硬件环境：

Phenom II X3 720 BE(B20 X4开核默频状态)

DDR2 800 4G双通道

785G（SB710,SATA2）

美光M4 64G


WINDOWS软件环境：

磁盘模式：AHCI

操作系统：WIN7 X64 MSDN旗舰版

磁盘控制器驱动：AMD SATA 1.2.1.321

系统部署环境：全新安装，系统盘美光M4 NTFS格式，默认4096簇

内存盘：RAMDisk  容量部署1G NTFS格式，其他默认

测试方式：使用系统图形界面自带的复制粘贴方式并统计速率。方法为从SSD用户区复制载体文件到内存盘，并且反向测试一次。只取启动后第一次测试的成绩（二次复制缓存干扰严重）




用于测试的载体：大约23万个4K的文件，大约960M，WINDOWS有个BUG，复制文件数量超过一定的值，explorer.exe进程可能崩溃，所以可能选取部分文件复制，并不影响测试精度。

关于WINDOWS自带的复制粘贴的数值统计误差：WINDOWS自身的文件复制速率统计有个毛病，对于完全相同尺寸的大量文件，在速率持续稳定的情况下，得到的时间和速率参考值比较稳定，如果文件大小不一导致速率稳定性低，那么得到的时间和速率参考值误差就比较大



实际测试：

这是从RAMDISK到SSD


速率非常的不理想，只有5.XX的速率，反过来复制也在5-7M每秒之间。这个时候我也使用了第三方的复制方法，比如FASTCOPY或者多线程复制软件多种，速率比WINDOWS自带的更低（1.X M/S的速率）。通过和浴室的讨论，我们查看的WINDOWS的Shell界面explorer.exe进程的CPU占用（复制粘贴是使用的这个进程），具体表现如下：



突然发现，这个进程的CPU占用率始终无法超越25%左右，有一个瓶颈。联想到25%为4线程CPU的正好一个单核心满载占用率，是否产生了单核心IPC瓶颈？关于explorer.exe这个进程在复制粘贴时是否没有为多线程优化？为此我求证了浴室，浴室在他的2600K上跑一次测试如下：


经过我和浴室反复的测试，RAM到SSD  SSD到RAM，关于explorer.exe进程的占用始终无法超越单线程瓶颈。


至此，在WIN7环境下，我们得出如下结论：系统界面的复制粘贴调用的Shell界面进程explorer.exe，这个进程左右着零碎文件的复制速度，又因为这个进程没有为多线程优化，在复制大量细小文件的情况下，首先会碰到CPU单线程IPC能力瓶颈，多线程的CPU并不能帮助提高复制粘贴细小文件的速率。在WIN7环境下的细小文件复制拼的就是CPU的单线程IPC能力




下一章节，将讲解在LINUX核心的操作系统下，细小文件的复制粘贴效率和WINDOWS有什么不同(尽请期待)。

LINUX部分软件环境（硬件环境和WIN相同）：

磁盘模式:AHCI

操作系统：ubuntu 11.10稳定发行版（AMD X64）

系统核心：Linux kernel v3.0.3

系统安装环境：删除M4 64G所有分区，全新安装

驱动程序：使用ubuntu的“附加硬件”功能自动更新到最新

分区和文件系统：sda1为EXT4 10G的系统分区、sda5为10G的SWAP空间、sda6为EXT4 39G的用户空间。

内存盘：ubuntu自身提供的SHM挂载，挂载路径为/run/shm（最大
2G自动管理，写入超越2G启动开启页面交换）

用于测试的载体：大约23万个4K的文件，大约960M

测试方式：使用系统图形界面自带的复制粘贴方式并统计速率。方法为从SSD用户区复制载体文件到挂载路径/run/SHM的内存盘，并且反向测试一次。只取启动后第一次测试的成绩（二次复制缓存干扰严重）




实际测试：


系统信息




测试载体属性




SSD往SHM挂载





SHM挂载往SSD



LINUX环境下并没有单线程瓶颈问题，4K小文件几乎已经跑到M4的QD1在我的平台下的能力极限。由此可以看出LINUX的文件复制性能目前只受硬件环境的限制

最近业余时间 在看介绍计算机系统的书籍 版主说的问题 主要还是和 操作系统的文件管理器设计有关吧

现在提不出有好的建议 等我多看几本书后在编辑

单盘上个有XOR的HBA卡看看会有改变么？……

多谢这样的技术文章

LINUX部分测试已经发布，这里已经出现的性能差异，大家已经可以得到常用操作系统环境下的区别了，MAC的部分找机会同平台部署一次（我的平台不一定合适）。

看来windows对多核优化没有linux好啊。
不过linux和unix设计就是针对多任务的。

自己倒是有台mac mini 2011
可惜SSD是Intel G2的，支持这样的技术文

linux文件复制性能很出色啊，不错

你的这个方法会因为你需要从Ramdisk上面读取随机数据造成性能损失，而且不是单纯的空间操作，在复制小文件时会有很多多余的信息，如文件名的要进行操作。
我有一个方法来测小块性能。
1.先用文件名为1，2，3等命名的4k文件填满整个硬盘。比如硬盘是16GB
2.根据所有的文件总数，隔着来删除文件。比如说你想进行操作的文件为1GB,那你就可以每16个文件，删掉一个，如你删掉文件编号为1,17,33,....,这样一直数下去。 这样你删完后的空间应该正好等于1GB，而这1GB绝对是彻底分散的。
3.在Ramdisk里面制作一个刚好1GB的文件，拷贝进去。 计算总完成的时间。这时的速度是未老化前的最坏小块的写速度。
4. 拷贝完成后，再重启后，再从这个盘把该文件拷出来到Ramdisk，计算总完成的时间。这个是最坏小块的读速度。

Lenovo 发表于 2012-3-15 02:37
你的这个方法会因为你需要从Ramdisk上面读取随机数据造成性能损失，而且不是单纯的空间操作，在复制小文件 ...

1. 仅仅因为SSD通过FTL映射表的方式动态映射LBA地址到PBA地址，并依赖这些动态映射来完成读写通道优化和各种读写有利的优化，而且在相对用户透明的背景时间片就一直在做这些可能的优化（数据搬移），这还包含了静态磨损平衡和动态磨损平衡等。

基于以上理由，你那些基于用户逻辑层的对数据人工产生自定义分布的操作，在数据物理分布上就没有任何可对应的关系（数据怎么安排是主控和固件算法决定的），没有可验证的控制数据分布意义存在。

2. 本文的目的就在于考察实际用户角度下的小文件复制性能。虽然例子有点极端（全4K），但只是为了说明一个多系统进程调度方面的区别是决定细小文件复制速度。从用户角度来说，并不存在你说的那种极限数据分布工况。仅从用户可能的角度枚举了一个稍微极端一点的例子。

3. 你前面谈到了文件分配表/MFT的文件操作开销导致的延迟，这也是属于正常的用户文件操作延迟，普通用户复制操作时并无法避免这样的延迟开销，那么他就应当属于正常的用户操作产生的开销范围。本文的命题并不是为了说明HDD数据碎片化导致寻道和潜伏期延迟对文件复制的影响，所以采用了RAMDISK和SSD的方式。仅仅只为说明不同的操作系统在对小文件操作上有什么区别，并给出问题的关键所在。

Lenovo 发表于 2012-3-15 02:37
你的这个方法会因为你需要从Ramdisk上面读取随机数据造成性能损失，而且不是单纯的空间操作，在复制小文件 ...

这个测评不是为了跑“理论极限”，那个不能证明和枚举任何对用户有益的信息。

用户关心的是，文件操作开销最大的情况下不同的操作系统有什么不同的表现（综合开销）。

为什么测试载体是4K这个尺寸的文件？因为如果采取大尺寸的文件做复制分块大小的话，那么可能导致文章中现在已经证明的基于单线程瓶颈造成复制体验的差异并不明显，甚至仅仅取决于设备速率（文中需要考察系统本身导致的瓶颈），这里面就包括了你想排除的那些“不必要”的开销，这并不是用户想要的“理论”结果。那么为什么正好是4K？因为PC很多IO操作的最小粒度就是基于4K这个尺寸，包括但不限于NTFS簇大小、内存/页面分页大小、我的SSD的PAGE大小等等，这些可以尽量减少各种IO操作“数据未对齐”产生的额外影响，尽量仅仅只比对和最终推理出不同操作系统对细小文件复制的关键影响到底是什么(用户角度，非理论)？

Lenovo 发表于 2012-3-15 02:37
你的这个方法会因为你需要从Ramdisk上面读取随机数据造成性能损失，而且不是单纯的空间操作，在复制小文件 ...

你要注意，我这里不是测的随机IOPS，如果需要测试随机4K能力（你说的小块能力，排开文件操作开销），显然用任意SSD测试软件就可以达成。


你那个方法我目前还不清楚到底是测的文件操作能力瓶颈（你的例子还是属于文件操作）还是随机IO或随机寻址能力瓶颈。你至少要排除一个出来吧？

我原本的意思是说，你这样没办法排除文件预读(或者是LBA)预读。
当两个或大量4k文件同时生成时，很可能是在相邻的LBA，那么系统去读取时速度会很快，因为会同时读取一大片的LBA，比如说256个block。这样的话你得到的速度会偏快。但是你这样又不能代表什么，因为用户使用时也可能文件就是散的。所以你得出来的值既不是最大值，也不是最小值。而是一个不能复制的参考值。 我估猜你每次测试的结果都会不大一样。
我的方法可以保证预读失效。 并且因为我操作的是一个整的1GB文件，所以肯定不是测的文件能力，而是验证的随机IO的和随机寻址能力。
你的第二个实验和我的实验刚好可以配套成为一个完整的实验。一个是文件操作，一个随机寻址操作。

Lenovo 发表于 2012-3-15 04:34
我原本的意思是说，你这样没办法排除文件预读(或者是LBA)预读。
当两个或大量4k文件同时生成时，很可能是在 ...

1. 随机IO和随机寻址能力跑个AS SSD就够了。而且这部分操作系统自身不为瓶颈，瓶颈在设备，无需考虑多系统对比取样，也不是本文的意义所在

2. 本文测试全部通过多次枚举验证数据的真实性，而且不只一个平台上完成测试，还有浴室的平台做佐证，得到的操作系统自身线程瓶颈导致的最终速率是趋向一致的（差额我认为是误差和CPU的IPC能力差额导致的）

3. 最关键的问题就在你说的那些恰恰证明了都还不是瓶颈，速率瓶颈仅仅只是操作系统自身，这也是找寻不同系统文件操作差异关键问题所在。你描述的某些其他的问题，如果是用户关注的内容的话，我会另开文章叙述技术相关。

Lenovo 发表于 2012-3-15 04:34
我原本的意思是说，你这样没办法排除文件预读(或者是LBA)预读。
当两个或大量4k文件同时生成时，很可能是在 ...

AS SSD的工作原理就是你描述的那个样子，而且不需要人工分配碎片化的LBA分布。它自创建测试临时文件，读写测试临时文件内随机的地址采样点。

Lenovo 发表于 2012-3-15 04:34
我原本的意思是说，你这样没办法排除文件预读(或者是LBA)预读。
当两个或大量4k文件同时生成时，很可能是在 ...

还有就是，文件复制粘贴并不是按LBA的连续地址来顺序读写，是按文件分配表或MFT描述的文件目录树结构来安排复制粘贴的顺序，这操作不一定是连续的LBA地址。

如果是拷贝粘贴，的确不一定是连续的LBA地址。
但是如果你连续创建文件时，就很可能是连续的。当然我没试过没确定。
你的文章标题是"4K随机性能等于4K小文件性能吗？" 你描述的是4k小文件，而我描述的是4k随机性能。。。
至于win7操作系统的限制，那是另外一个题目了。