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

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

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

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

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

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

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

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

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

复制粘贴文件  

和文件名有关的，复制时会有先后的，数据就算没有碎片一次能读完，找文件时却是跳的。
你复制1000个文件，复制到一半断开，对对文件名。
每次是不是一样？

4K随机性能等于4K小文件性能？理论应该等于，理由是没有寻道，误差不计算。

只有5.XX的速率，反过来复制也在5-7M每秒之间。
和系统有关，和软件有关，还有个一般人不注意的ecc，读写是有错误的，错误多的话，速度就会被拖慢，要再次读写，错误率不可能为零，而且是个很大的数字。
中间加杂的东西越多，速度越慢，如果要等一个好了再开始下一个，4K随机性能是等还是和下一个一起？4K随机性能是几线程的？要先自己开发个单线程4k随机软件了。

用u盘测试可以更好的得出结果，单通道。

stevenxu 发表于 2012-10-9 16:22
只是单线程的问题吗？如果开4个进程同时运行呢？

和用户层面的逻辑线程无关，也就是和你同时复制的线程无关。是操控复制的那个进程的单线程瓶颈。您懂了吗？

只是单线程的问题吗？如果开4个进程同时运行呢？

以前似懂非懂，今天再看一遍，感觉懂了。下次再看也许才是真懂

linux必须和windows server 2008或者2012一齐测试，因为linux本身就是基于服务器的高级系统

robocopy 32线程下速度没区别，那个如果网络传输的话会有优势。

win7有个robocopy命令，据说能多线程复制

vgxd 发表于 2012-3-24 23:24
lz用的什么ramdisk？那个免费的ramdisk性能非常差，4k的性能是个位数的
相比之下，superspeed的ramdisk plu ...

已经排除是RAMDISK的问题了，浴室那边的复制是SDD TO SDD，结果是一致的

lz用的什么ramdisk？那个免费的ramdisk性能非常差，4k的性能是个位数的
相比之下，superspeed的ramdisk plus 4k性能非常好
但是ramdisk都有个缺点就是速度太快导致cpu占用率太高

那个…… 我比较好奇RoC在这里能否代替CPU？……

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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

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

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