【IT168 专稿】众所周知，随使用时间的推移，SSD的性能会逐渐下降，特别是早期SSD产品更是如此，新的控制器通过各种技术有效缓解了这个问题。在这篇文章中，我们将执行一些企业级SSD基准测试，通过对比前后测试结果，加深对SSD性能下降的理解。

　　SSD性能问题回顾

　　前面我们分析了SSD性能问题的一些根源，晶体管的设计，底层NAND芯片的设计，以及SSD硬盘自身的设计都是其性能下降的根本原因。

　　在回顾SSD硬盘结构部分，我们曾介绍过SSD是以块为单位进行擦除的，大小通常是512KB，这意味着如果某个块上的一个页面(4KB)发生了变化，整个SSD都需要重写，重写过程需要经历漫长的“读-修改-擦除-写”周期，“读”通常指的是将块上的所有数据读入到缓存中，接着将“修改的”数据和缓存中已有的数据合并，然后“擦除”那个块上的全部数据，最后将缓存中的新数据“回写”到已被擦除的块上。

　　有人认为这个过程应该不需要多长时间，但SSD的擦除速度要比读取速度慢好多倍，导致整个“读-修改-擦除-写”周期花费的总时间变长。更糟糕的是，“读-修改-擦除-写”周期会产生一个所谓的写放大系数，它指的是即使是块上单个页面发生变化或更新，也会导致使用额外的写周期，理想情况下，写放大系数应等于1，即向存储介质写入数据时，不需要额外的写周期，如果写放大系数大于1，则意味着向存储介质写入数据时，不止发生一次写入操作，早期的SSD写放大系数通常是远远大于1。因此不要忘了SSD的写操作周期的限制，SLC SSD大约是10万次，MLC SSD大约只有1万次。

　　SSD硬盘制造商其实早已知道这些问题，它们已经想出许多方法来克服这些问题，写放大系数也变得越来越接近于1。其中一种技术叫做写合并，控制器将多个写操作收集到一起，然后一次性将这些数据写入到SSD的块上。合并的目标是将多个小的写操作合并成一个大的写操作，大多数时候，相邻页面的数据会同时发生变化，这些页面很可能属于同一个文件。通过写合并技术，写放大系数大大减小了，SSD的性能也显著提高了，但这也与发送数据的方式，以及数据块是否同属于同一个文件，或是否在同一时间发生变化有关。

　　另一种技术叫做超量供给，它保留了一定数量的储备块，连操作系统也不可见，例如，假设一块SSD硬盘的总容量是75GB，只将其中60GB暴露给操作系统，剩下的用作保留块，相当于是一个可用块池，操作系统无法占用，它们只是用来帮助提高性能的，确保任何时候都有可用的块，避免应用程序将数据真实写入SSD之前不会因漫长的“读-修改-擦除-写”周期而产生性能瓶颈。这个技术也能间接提高SSD的使用寿命，因为有一部分块的写周期相比其它块而言要少，以后可以切换保留池中的块，有助于均衡SSD存储块的磨损。

　　第三个技术是所谓的TRIM命令，SSD最大的性能问题之一是，写操作发生在一个尚未擦除的页面上，这个时候，包含该页面的整个块都要被读入到缓存中，新数据和块中已有的数据合并，再擦除整个块上的数据(这个操作需要的时间最长)，最后将缓存中的数据回写到块上，这种“读-修改-擦除-写”过程需要的时间比仅仅只有“写”操作的时间要多得多，TRIM命令告诉SSD控制器，当一个页面不再需要时，就将其标记为擦除，这样SSD控制器就可以将新数据写入到一个干净的页面上，从而避免完整的“读-修改-擦除-写”周期，只留下“写”周期，因此整体写入性能要好得多。

　　这些技术不同程度地提高了SSD的性能和使用寿命，在设计时需要进行权衡和取舍，因为它们需要更精密的控制器，因此设计和制造成本会更高，超量供给还会使硬盘的可用容量减少，SSD制造商必须综合考虑它们的优缺点，同时兼顾性能和成本，才能设计出性价比很高的产品。

　　在这篇文章中，我要测试一款企业级SSD硬盘：英特尔X25-E，我会先执行一些基准测试，然后执行一些I/O密集型测试，最后再执行基准测试，通过对比两次基准测试结果，找出性能下降的迹象。

　　基准测试方法和设置

　　很多时候，除了可以提供比厂商宣传资料更多的信息外，基准测试没什么用，我会遵循一些原则提高基准测试质量，如：

　　? 解释基准测试背后的动机。
　　? 使用相关且有用的存储基准测试。
　　? 尽可能详细描述基准测试。
　　? 这些测试持续运行时间将超过60秒。
　　? 每个测试执行10次，计算出平均值和标准偏差。

　　遵循这些原则可以使基准测试变得更有用。

　　测试系统的配置如下：

• GigaByte MAA78GM-US2H 主板
• 一颗AMD Phenom II X4 920 CPU
• 内存8GB (DDR2-800)
• Linux 内核2.6.34 (只提供了bcache补丁)
• 操作系统和启动盘位于一块IBM DTLA-307020硬盘上 (20GB，Ultra ATA/100)
• /home位于一块希捷ST1360827AS硬盘上
• 两块临时数据存储硬盘，希捷ST3500641AS-RK，缓存16MB，操作系统识别为/dev/sdb和/dev/sdc。
• 一块英特尔X25-E SLC SSD硬盘(64GB)连接到一个SATA端口 (操作系统识别为/dev/sdd)。

　　我使用的系统是CentOS 5.4，但内核是用的我自己的编译的2.6.34版本，打了一些补丁，本文后面的部分将称之为2.6.34+，选择2.6.34内核是因为它支持TRIM命令，文件系统使用ext4，因为它也支持TRIM命令，创建ext4文件系统的细节很重要，下面专门用一小结的内容来描述。

　　创建ext4文件系统

　　在研究如何在SSD上创建ext4文件系统时，我发现了ext4主要维护者(Theodore Ts'o)的博客，Theodore Ts'o的博客详细介绍了如何将英特尔SSD格式化成ext4文件系统，第一步是分区，命令如下：

　　[root@test64 ~]# fdisk -H 224 -S 56 /dev/sdd

　　这里的-H参数指的是“头”数量，-S参数指的是每磁带的扇区数量，fdisk总是把任何硬盘当作旋转机械硬盘对待，因此有些参数对SSD硬盘来说是没有任何意义的，根据Theodore的建议，我使用下面的命令创建了一个ext4文件系统：

　　[root@test64 ~]# mke2fs -t ext4 -E stripe-width=32 resize=500G /dev/sdd1

　　“stripe-width=32”是Theodore推荐的，据说对性能有帮助，“resize=500G”将文件系统大小限制在500GB以内，因为文件系统超过500GB空间浪费就很大，至于文件系统，当然选择了ext4。

　　我从以下三个方面测试了这块SSD：

　　1、 吞吐量
　　2、 IOPS
　　3、 元数据

　　第一个测试侧重于SSD的带宽容量，第二个测试侧重于响应I/O请求的速度，第三个测试更侧重于文件系统。测试吞吐量和IOPS我选择了IOzone，测量元数据性能我使用了Metarates。

　　IOzone

　　IOzone是最流行的吞吐量基准测试工具，部分原因是因为它是开源的，是用很朴实的ANSI C编写的(我没有讽刺它的意思)，也许更重要的是它能执行一些不常见的基准测试，它支持单线程，多线程和多客户端测试。IOzone的基本思想是将给定的文件分解成记录，记录以某种方式写入或读取，直到达到文件大小，因此IOzone可以执行许多种类的测试，本文将用到下面这些测试类型：

　　写

　　这是一个相当简单的测试，模拟写入新文件，由于需要为文件创建新的元数据，大多数时候，写入新文件的速度要比重写现有文件要慢，使用指定长度(可由用户指定，也可由IOzone自动指定)的记录写文件，直到达到文件总长度。

　　重写

　　这个测试和写测试类似，但测试的是已存在文件的写入性能，由于文件已经存在，元数据也就创建好了，因此重写性能普遍要比写入性能要好，它首先打开已存在的文件，将文件指针置于文件的开头，然后使用指定长度的记录写入到打开的文件描述符，直到达到文件的大小，最后关闭文件，更新元数据。

　　读

　　这个测试读取已存在的文件，它读取整个文件，一次一个记录。

　　重读

　　这个测试读取最近读取过的文件，它非常有用，因为操作系统和文件系统会在缓存中保留最近读取文件的内容，因此重读的性能也要好于读取的性能，但如果文件的大小远远大于缓存，则重读的效果并不佳，因为缓存装不下整个大文件，最终还是要从磁盘上寻找文件对应的存储块。

　　随机读

　　这个测试随机访问文件中的任意位置，它的性能受多种因素的影响，包括操作系统缓存，磁盘数量和它们的配置，磁盘寻道延迟，磁盘缓存等。

　　随机写

　　随机写测试是测试随机写入文件任意位置时的性能，文件始终处于打开状态，直到写满文件。

　　反向读取

　　这是一个特殊的文件系统测试，它反向读取一个文件，如MSC Nastran就会反向读取文件，部分文件系统和操作系统不能检测到这种访问模式，因此也无法提高访问性能，在这个测试中，打开一个文件，文件指针向前移动一个记录，读取文件时就需要向后读取一个记录，然后文件指针又向后移动两个记录，依此类推，完成文件的读取的操作。

　　改写记录

　　这个测试是测试写和重写文件中的一个特殊点时的性能，这个测试非常有趣，因为它可以突出文件系统和/或操作系统内的“热点”功能，如果热点足够小，可以适应各种缓存大小，如CPU数据缓存，TLB，操作系统缓存，文件系统缓存等，那么性能将会非常好。

　　跨越式读取

　　这个测试以一种跨越式方法读取一个文件，例如，你可以先零偏移读取长度为4KB的文件内容，然后向前搜索200KB再读取4KB的文件内容，再向前搜索200KB，依此类推，按照相同的跨度向前读取，两次读操作之间的距离(这里是200KB)叫做步幅，如果步幅和RAID条带配置不一致，就容易产生性能问题。

　　fwrite

　　这个测试是测量使用库函数fwrite()写入文件的性能，fwrite()是一个二进制流函数，一般情况下，它执行的是缓冲区写入操作，缓冲区位于用户空间(不属于系统缓存)，这个测试首先在用户空间缓冲区中创建记录长度大小的缓冲区，然后写入到磁盘，重复这个动作，直到整个文件创建好，这个测试和创建一个新文件的写入测试类似，关键还是看元数据的性能。

　　frewrite

　　这个测试和fwrite类似，但它测试的是库函数frewrite()，理想情况下，它的性能应该比fwrite要好，因为它使用的是现有文件，不用担心元数据性能。

　　fread

　　这个测试是测量库函数fread()读取文件的性能，它打开一个文件，以记录长度将文件内容读取到用户空间的缓冲区中，重复这个操作，直到整个文件全部读入。

　　freread

　　这个测试和reread测试类似，但它使用的是fread()库函数，它读取最近打开的文件，因此可以使用文件系统或操作系统的缓冲区提高读取性能。

　　虽然还有其它测试选项，但这里列举的已经够多了基本上覆盖了大部分应用程序的访问模式。

　　对IOzone来说，系统规格是相当重要的，因为它们会影响到命令行选项，特别是，系统内存容量是很重要的，因为它对缓存效率的影响是很大的，如果问题大小足够小以适应文件系统或操作系统缓存(或部分)，结果可能会完全不一样，例如，在只有1GB内存的系统上和在有8GB内存的系统上运行相同大小的问题，其结果会有很大的差异。

　　在这篇文章中，缓存的影响是有限的，如果运行非常大的问题，并强制操作系统消除几乎所有缓存，缓存影响是不能完全消除的，减少缓存影响最好的办法是使文件比主内存更大，这里选择的文件大小是16GB，相当于主内存的两倍，我们是根据以往的经验和网上流传的一些说法选择的。

　　我们测试了四种记录大小：1MB、4MB、8MB和16MB，总文件大小为16GB，因此分别有16000、4000、2000和1000条记录，执行测试的命令如下：

　　./IOzone -Rb spreadsheet_output_1M.wks -s 16G -r 1M > output_1M.txt
　　The command line for the second record size (4MB) is,
　　./IOzone -Rb spreadsheet_output_4M.wks -s 16G -r 4M > output_4M.txt
　　The command line for the third record size (8MB) is,
　　./IOzone -Rb spreadsheet_output_8M.wks -s 16G -r 8M > output_8M.txt
　　The command line for the fourth record size (16MB) is,
　　./IOzone -Rb spreadsheet_output_16M.wks -s 16G -r 16M > output_16M.txt

　　使用IOzone执行IOPS测试

　　执行IOPS(每秒执行的I/O操作数)测试时我也使用了IOzone，此外，IOzone也常常用来测试吞吐量，具体地说就是它能测试连续读/写IOPS和随机读/写IOPS。我们使用IOzone测试了四种IOPS测试：

•  读
•  写
•  随机读
•  随机写

　　和吞吐量测试一样，IOPS测试使用的文件大小也是系统主内存的两倍，我们的目标是让文件大小超过Linux可以缓存的容量大小，和前面一样，测试使用的文件大小为16GB，四个记录大小：4KB、8KB、32KB和64KB，选择这些大小是因为越小的记录大小运行时间越长，每种测试我们都分别执行了10次，因此基准测试时间很长(以周计算)。此外，4KB是IOPS测试的典型记录大小。执行测试的命令如下：

　　/iozone -Rb spreadsheet_output_4K.wks -O -i 0 -i 1 -i 2 -e -+n -r 4K -s 16G > output_4K.txt
　　The command line for the second record size (8KB) is,
　　./iozone -Rb spreadsheet_output_8K.wks -O -i 0 -i 1 -i 2 -e -+n -r 8K -s 16G > output_8K.txt
　　The command line for the third record size (32KB) is,
　　./iozone -Rb spreadsheet_output_32K.wks -O -i 0 -i 1 -i 2 -e -+n -r 32K -s 16G > output_32K.txt
　　The command line for the fourth record size (64KB) is,
　　./iozone -Rb spreadsheet_output_64K.wks -O -i 0 -i 1 -i 2 -e -+n -r 64K -s 16G > output

　　Metarates

　　HPC存储系统最常用的基准测试叫做Metarates，它由UCAR(University Corporation for Atmospheric Research)公司开发，实际上它是一个使用POSIX系统调用测试元数据性能的MPI应用程序。

• Create()：打开或创建一个文件。
• Stat()：获得文件状态。
• Unlink()：删除引用的文件名。
• Fsync()：同步文件的内核状态。
• Close()：关闭文件描述符。
• Utime()：修改文件最后访问和修改时间。

　　使用这些系统调用，Metarates的主要分析选项如下：

• 测试文件创建/关闭(每秒创建/关闭的文件)的速度。
• 测试utime调用的速度(每秒utime操作次数)。
• 测试stat调用的速度(每秒stat操作次数)。

　　Metarates可以设置每MPI进程写文件的数量，一个MPI应用程序可以有N个进程，N最小为1，还可以设置文件是写到单个目录还是多个目录，它也可以使用系统调用fsync()同步文件的内核状态。

　　记住Metarates是一个MPI应用程序，允许我们选择进程(核心)的数量，我们测试时选择了1、2和4个核心(三个独立的测试)，这些测试被标记为NP=1(1核心)，NP=2(2核心)和NP=4(4核心)，NP表示进程的数量。执行这些测试的命令如下：

　　time mpirun -machinefile ./machinefile -np 4 ./metarates -d junk -n 1000000 -C -U -S –u

　　这里的“-np”表示进程数量(本例中是4)，“-machinefile”指的是运行时使用的系统主机名列表(本例是一个./machinefile文件，包含了测试机器的主机名)，结果输出到一个名为metarates_disk.np_4.1.out的文件中，请自行理解文件的命名规则。

　　我们执行了三种不同的性能测试：

• 文件create和close速度(每秒的次数)。
• 文件stat速度(每秒stat操作次数)。
• 文件utime速度(每秒utime操作次数)。

　　测试过程

　　正如前面提到的，我们先在干净的磁盘上执行基准测试，然后执行I/O密集型压力测试，最后再次执行基准测试，并将前后两次基准测试的结果进行对比，基准测试的设置已经讨论过了，但“折磨”(压力)测试还需要进一步说明。

　　I/O密集型测试的目的是为了考验底层存储介质的性能，顺带也测试了文件系统的性能，注意我们要测试的是一块英特尔SSD，从测试结果看各种提高性能的技术究竟对性能有何影响，因此I/O密集型测试也要针对各种文件大小和记录大小进行测试，我们选择的测试工具是IOR，它是一款基于MPI的I/O基准测试工具，支持N-N(N个客户端读/写N个文件)和N-1(N个客户端读/写单个文件)性能测试。根据测试的类型，IOR有很多选项，但最基本的是方法是将文件分解成多个段，段再按顺序分解成块，块上的数据以“t”为单位进行传输(t表示传输大小)，下图显示了一个文件是如何用这些参数构造的。

图 1 IOR文件布局

　　为简单起见，段大小和块大小设为一样，即一个段只包含一个块。

　　我们运行了两个IOR命令，每个重复执行10次，第一个IOR命令如下：

　　mpirun -np 4 -machinefile ./machinefile ./IOR -a POSIX -b 64k -F -i 10 -s 200000 -t 4k

　　其中“mpirun -np 4 -machinefile ./machinefile”全部是MPI命令选项。

　　l -np 4：表示进程数为4。

　　l -machinefile ./machinefile：指定主机名列表的位置，由于我们是在单机上测试，因此只列出了本系统的主机名，每个测试对应一条，因此总共有4条记录。

　　l ./IOR：可执行文件的名称。

　　IOR的真正运行参数是放在可执行文件IOR之后的，参数解释如下：

　　l -a POSIX：告诉IOR使用POSIX API(不是MPI-IO或其它API)。
　　l -b 64k：块大小，这里是64KB。
　　l -F：告诉IOR每个进程使用一个文件。
　　l -i 10：告诉IOR运行10次测试。
　　l -s 200000：告诉IOR段的数量，这里是200000。
　　l -t 4k：告诉IOR传输大小，这里是4KB。
　　l -vv：告诉IOR输出详细信息。

　　IOR将会使用前面的参数执行读和写测试，你可以根据块大小计算出文件的大小，每个段的块数，以及段的数量，下面我们略去了IOR的输出内容。但是从输出结果可以看出文件的总大小是48.83GB，需要注意的是，文件大小必须控制在64GB以内，因为磁盘格式化后的总大小才58.7GB，在前面的部分测试中，IOR在测试系统上运行时用时7分钟。

　　第二个IOR命令和第一个类似，但块大小，传输大小和段数量不同，命令如下：

　　mpirun -np 4 -machinefile ./machinefile ./IOR -a POSIX -b 1M -F -i 10 -s 14000 -t 256k

　　下面我们同样略去了大部分代码，只展示部分输出结果如下：

　　Operation Max (MiB) Min (MiB) Mean (MiB) Std Dev Max (OPs) Min (OPs) Mean (OPs) Std Dev Mean (s)Op grep #Tasks tPN reps fPP reord reordoff reordrand seed segcnt blksiz xsize aggsize

　　--------- --------- --------- ---------- ------- --------- --------- ---------- ------- -------

　　write 197.95 197.68 197.79 0.09 0.06 0.06 0.06 0.00 283.12821 4 4 10 1 0 1 0 0 14000 1048576 262144 58720256000 -1 POSIX EXCEL

　　read 242.10 241.06 241.56 0.31 0.07 0.07 0.07 0.00 231.82731 4 4 10 1 0 1 0 0 14000 1048576 262144 58720256000 -1 POSIX EXCEL

　　Max Write: 197.95 MiB/sec (207.56 MB/sec)

　　Max Read: 242.10 MiB/sec (253.86 MB/sec)

　　Run finished: Tue Sep 28 11:57:59 2010

　　这次IOR测试使用更大的文件(54.69GB)，测试耗时近90分钟。

　　和I/O密集型测试一样，这两个IOR命令各运行了10次，但文件大小更大，给磁盘带来的压力也更大。

　　测试结果：吞吐量结果（一）

　　我们用所有结果的平均值绘制成条形图，并用误差线显示了标准偏差，每个测试都有两个条形图 – “前”和“后”，“前”结果指的是使用IOR压力测试之前的基准测试结果，“后”结果指的是压力测试之后的基准测试结果，我们指出了“前”和“后”两个结果之间的显著区别。

　　我们将结果分为三部分呈现：吞吐量(IOzone测试结果)，IOPS(也是IOzone测试结果)和元数据(Metarates测试结果)。

　　吞吐量结果

　　第一个吞吐量测试结果是写吞吐量测试，如下图所示。

图 2 IOzone写吞吐量测试结果(KB/s)

　　从上图可以看出，写吞吐量性能在执行I/O密集型测试后的表现更好，但我们还需要注意标准偏差，如果两个测试的差距落在标准偏差范围内，就不能轻易地得出“后”比“前”性能要好的结论。

　　例如，对于1MB的记录大小，你可能会认为“后”比“前”结果要好，但两个测试之间的差距落在标准偏差范围内，因此不能说“后”比“前”性能更好。

　　图3显示了重写吞吐量测试结果。

图 3 IOzone重写吞吐量测试结果(KB/s)

　　从上图可以看出，在重写吞吐量基准测试中，记录大小为4MB时，“前”比“后”结果更快，但差距是很小的(约3.5%)，至于其它记录大小，压力测试前后的重写吞吐量性能差异都落在标准偏差范围内，两者之间的差距基本上可以忽略。

　　图4显示了读吞吐量测试结果。

图 4 IOzone读吞吐量测试结果(KB/s)

　　尽管我们看到的是“前”比“后”性能要快，但两者之间的差异均落在标准偏差范围内，因此也不能轻易说“前”比“后”性能要好。

　　图5显示了重读吞吐量测试结果。

图 5 IOzone重读吞吐量测试结果(KB/s)

　　在这个测试中，“前”和“后”测试结果之间的差距也很小。

　　图6显示了随机读吞吐量测试结果。

图 6 IOzone随机读吞吐量测试结果(KB/s)

　　在这个测试中，我们真正看到了“前”和“后”测试之间的差距，从上图可以看出，“前”性能明显好于“后”性能，对于4MB、8MB和16MB记录大小，“前”结果比“后”结果要高出13-15%。

　　图7显示了随机写吞吐量测试结果。

图 7 IOzone随机写吞吐量测试结果(KB/s)

　　这些测试结果和随机读测试结果有点不一样，记录大小为4MB时，压力测试前的性能(前)比压力测试后(后)的性能要好得多，但在其它记录大小情况下，两者之间的差距是很小的，因此也不能轻易地说一个比另一个好。

　　测试结果：吞吐量结果（二）

　　图8显示了反向读吞吐量测试结果。

图 8 IOzone反向读吞吐量测试结果(KB/s)

　　从上图可以看出，三个较大记录大小的“前”性能明显好于“后”性能，差距大约在17-20%左右。

　　图9显示了记录重写吞吐量测试结果。

图 9 IOzone记录重写吞吐量测试结果(KB/s)

　　在这个测试中，压力测试前后的性能表现旗鼓相当。

　　图10显示了跨越式读吞吐量测试结果。

图 10 IOzone跨越式读吞吐量测试结果(KB/s)

　　对于这个特殊的I/O模式，我们发现压力测试前的性能明显好于压力测试后的性能，对于较大的三个记录大小尤其如此，“前”结果比“后”结果要快22-23%左右。

　　图11显示了fwrite吞吐量测试结果。

图 11 IOzone Fwrite吞吐量测试结果(KB/s)

　　在这个测试，压力测试前后的性能差距不明显，可以忽略。

　　图12显示了frewrite吞吐量测试结果。

图 12 IOzone Frewrite吞吐量测试结果(KB/s)

　　和fwrite测试结果一样，压力测试前后的性能差距并不明显。

　　图13显示了fread吞吐量测试结果。

图 13 IOzone Fread吞吐量测试结果(KB/s)

　　在这个测试中，虽然压力测试前后的性能存在一定的差距，但都落在标准偏差范围内，因此也不好说谁赢谁输。

　　图14显示了freread吞吐量测试结果。

图 14 IOzone Freread吞吐量测试结果(KB/s)

　　在这个测试中，压力测试前后的性能差距比较明显，对于三个较大记录大小的测试结果差距，大约保持在9-13%左右。

　　总体来看，压力测试前存在一定的性能优势，具体表现在：

• 随机读(13-15%)。
• 随机写(4MB记录大小，20%)。
• 反向读(较大记录大小，17-20%)。
• 跨越式读(较大记录大小，22-23%)。
• Freread(较大记录大小，9-13%)。

　　随机I/O性能差距也非常有趣，因为许多客户端应用程序访问相同的存储时，I/O模式基本上都是随机的，因此设备的随机性能是最重要的。

　　测试结果：IOPS结果

　　我们总共执行了四种IOPS测试：写IOPS，读IOPS，随机写IOPS和随机读IOPS。

　　图15显示了写IOPS测试结果。

图 15 IOzone 写IOPS测试结果

　　压力测试前后写IOPS测试结果有些差距，记录大小为8KB时前后结果差距有点大，但标准偏差相互都很接近，因此总体来看性能不存在明显的差距。

　　图16显示了读IOPS测试结果。

图 16 IOzone 读IOPS测试结果

　　在这个测试中，压力测试前后的性能差距很小，可以忽略。

　　图17显示了随机写IOPS测试结果。

图 17 IOzone随机写IOPS测试结果

　　从上图可以看出，仅记录大小为32KB和64KB时，压力测试前后的性能存在明显的差距，记录大小为32KB是，“前”比“后”结果要高10.8%，记录大小为64KB时，“前”比“后”结果高8.7%。

　　图18显示了随机读IOPS测试结果。

图 18 IOzone 随机读IOPS测试结果

　　在这个基准测试中，较小记录大小和较大记录大小压力测试前后的结果发生了有趣的变化，对于32KB和64KB记录大小，压力测试后的性能要明显好于压力测试前的性能，例如32KB记录大小，“后”比“前”高14.26%，对于64KB记录大小，“后”比“前”高12.6%。

　　对于IOPS测试，总体来看，压力测试前后的性能差距是很小的，但在随机IOPS测试中，我们发现压力测试前后的确存在一定的性能差距。

　　元数据测试结果

　　我们执行了三种元数据测试：文件open/close性能，文件stat性能和文件utime性能。

　　图19显示了元数据文件create/close测试结果。

图 19 Metarates元数据文件create/close测试结果(每秒的操作次数)

　　从上图可以看出，真正存在性能差距的是4个进程时，压力测试前比压力测试后的性能要好9%。

　　图20显示了元数据文件stat测试结果。

图 20 Metarates元数据文件stat测试结果(每秒操作次数)

　　从上图可以看出，NP=1时，“后”比“前”性能好3.88%，NP=2时，“后”比“前”性能好6.58%，NP=4时好3.44%。

　　图21显示了元数据文件utime测试结果。

图 21 Metarates元数据文件utime测试结果(每秒操作次数)

　　在这个测试中，压力测试前后虽然存在一定的性能差距，但都落在标准偏差范围内，因此不能说谁输谁赢。总的说来，元数据性能是“后”比“前”好。

　　总结：企业级SSD性能下降并不明显

　　本次基准测试的目的是使用支持TRIM的Linux内核测试一款企业级SSD，通过I/O密集型测试前后的基准测试对比来分析性能下降的原因。

　　为了对比压力测试前后的性能，我们使用了三种类型的基准测试：吞吐量测试，IOPS测试和元数据测试。首先在全新的磁盘上执行基准测试，然后执行I/O密集型压力测试，最后再执行基准测试。测试所用的是一块英特尔X25-E SSD，CentOS 5.4操作系统，2.6.34Linux内核，并打了bcache补丁，文件系统是ext4，因为它支持TRIM命令，磁盘经过最优配置，以便获得最好的性能，配置建议全部来自ext4文件系统主要维护人员Theodore Ts'o的博客。

　　我们使用了两个基准测试工具：测试吞吐量和IOPS的IOzone和测试元数据性能的Metarates，总共执行了13个吞吐量测试，4个IOPS测试，3个Metarates测试，每个测试执行10次。

　　虽然压力测试前后的性能差距不太大，但还是有一些区别。

• 随机读吞吐量：记录大小为4MB、8MB和16MB时，“前”结果更好，比“后”结果要好13-15%左右。
• 随机写吞吐量：记录大小为4MB时，“前”结果比“后”结果好20%左右。
• 反向读吞吐量：记录大小为4MB、8MB和16MB时，“前”结果比“后”结果要好17-20%。
• 跨越式读吞吐量：记录大小为4MB、8MB和16MB时，“前”结果比“后”结果要好22-23%。
• Freread吞吐量：记录大小为4MB、8MB和16MB时，“前”结果比“后”结果要好9-13%。
• 随机写IOPS：记录大小为32KB时，压力测试前比压力测试后的性能好10.82%，记录大小为64KB时，压力测试前比压力测试后的性能好8.73%。
• 随机读IOPS：记录大小为32KB时，压力测试后的性能比压力测试前的性能好14.26%，64KB时好12.6%。
• 文件close/open元数据：NP=4时，“前”比“后”性能好9%。
• 文件stat：NP=1时，“前”比“后”性能好3.88%，NP=2时好6.58%，NP=4时好3.44%。

　　从测试结果可以看出，英特尔X25-E的表现非常优秀，即使是经历了I/O密集型压力测试后也是如此，总体来说是压力测试前的性能好于压力测试后的性能，但也有例外情况，但我认为前后的差距还是很小的，可以有把握地说，这款企业级SSD随时间推移性能不会明显下降。如果你还担心SSD硬盘会随时间推移速度变得越来越慢，读完本文后你应该打消这个疑虑了。