相关合集：
相关热搜：
系统漏洞是指电脑的操作系统和应用软件在逻辑上的缺陷和错误，被不法者利用，通过网络植入木马、病毒等方式来攻击或控制整个电脑，窃取您电脑中的重要资料和信息，甚至破坏您的电脑。
高速下载地址
联通下载地址
电信下载地址
移动下载地址
其他下载地址
(您的评论需要经过审核才能显示)
还没有评论！！
热门关键词性能诊断123（102）
lmbench 3.0-a9
测试包括文件读写、内存操作、进程创建销毁开销、网络等性能
unixbench5.1.2
Linux下的VPS性能测试软件
dbench&3.04
文件系统基准，产生良好的文件系统负载&
CPU性能、稳定性测试
stressapptes revision 1.0.1_autoconf
内存稳定性测试
memtester V4.1.2
内存压力测试
stream &v 5.9
内存带宽测试
iozonetest3a revision 3.338
磁盘I/O性能、稳定性测试
x11perf v 1.5
测试显卡性能
Linpack v2.0
测试内核和内核相关特性
iperf-2.0.4、netperf-2.4.5
测试网络性能
一、lmbench&&&&& 版本：lmbench-3.0-a9
测试包括文件读写、内存操作、进程创建销毁开销、网络等性能的基准测试。
#tar -xvf lmbench.
#cd lmbench-3.0-a9;
接下来的设置除了MB（默认值较大，耗时较长或程序运行不起来，取值大于4倍的外部缓存小于80%的物理内存即可）和Mail results（输入no敲回车，意思不发送邮件回执）外都选默认值。
程序运行结束后查看结果：
#make see；
敲回车后提示
cd results && makesummary &summary.out 2&summary.errs
cd results && makepercent &percent.out 2&percent.errs
#cd results
#vi summary.out查看结果
二、unixbench&&& 版本：unixbench-5.1.2
#tar -xvf unixbench.tar.
#tar -xvf unixbench-5.1.2.
#cd unixbench-5.1.2;
#./Run -c 4;
参数-c后接的是跑的线程，若跑单线程，则#./Run，敲回车即可。
测试结果直接显示在终端，也可以在运行命令后加上测试结果的保存路径来保留测试记录，即#./Run -c 4 &/opt/unixbench-result.txt
三、dbench
版本dbench-3.04
测试文件系统基准，产生良好的文件系统负载。
#tar -zxvfdbench-3.04.tar.
#cd dbench-3.04;
#./autogen.
#./dbench [线程数] -t [时间以秒为单位]，例如：./dbench 100 -t 36000（意思是开启100个进程跑10个小时）
结果显示在终端，也可以在运行命令后加上测试结果的保存路径来保留测试记录，即#./dbench 100 -t 36000 &/opt/dbench-result.txt。
四、spec2000
spec2000-new安装与运行：
1、新建目录：/home/benchmark
# mkdir /home/benchmark
2、将spec2000-new.tgz压缩包放在/home/benchmark下，并解压：
#cp -rf 【文件路径】 /home/benchmark
#cd /home/benchmark
#tar -xvf spec2000-new.tgz
# cd& /home/benchmark/spec2000-new/
# ./myrun.sh
可以在运行命令后加上测试结果的保存路径来保留测试记录，即# ./myrun.sh &/opt/spec2000-result.txt。
五、stessapptest
SAT版本：1.0.1，内存稳定性测试。
进入stressapptest文件夹，运行#./stressapptest -M 1200 -s 60
-M后是测试内存大小，-s后是测试时间，单位秒。
测试结果显示在终端，Status:PASS-pleaseverify no corrected errors，也可以在运行命令后加上测试结果的保存路径来保留测试记录，
即#./stressapptest -M 1200-s 60 &/opt/sat-result.txt。
六、memtester&&&& 版本memtester-4.2.1安装与运行：
#tar -zxvfmemtester-4.2.1.tar.gz
#cd memtester-4.2.1
#make install
cat /proc/meminfo 查看memory free size N KB
cat /proc/cpuinfo& 查看系统中CPU的核心数n
在根目录下建一mem文件夹
同时开n个线程运行memtester可以节约测试时间
./memtester N/1024n runs&/mem/1&
./memtester N/1024n runs&/mem/n&
查看记录：
cat /mem/1
cat /mem/2
七、stream&&& 安装：
(#tar -zxvf stream.tgz)
#cd stream
#gcc stream.c -o stream
测试结果直接显示在终端，也可在运行命令后加测试结果保存路径来保留测试记录，即#./stream &/opt/stream-result.txt。
结果不理想的话，可以调整stream.c文件中N的值，默认N=2000000，X86平台一般要求N=(1级cache+2级cache)，单位B。
八、iozone&&& 版本iozone3_308安装与运行：
#tar -zxvfiozone3_308.tar.
#cd iozone3_308/src/
#make linux-
#./iozone -i 0 -i 1 -s 160G-Rab /opt/HDDstress.xls
测试文件大小最好为内存的两倍以上，防止内存缓存，造成数值不准确
九、x11perf&& 版本x11perf-1.5：
1）解压x11perf-1.5.tar.gz，
#tar -xvf x11perf-1.5.tar.gz
2）安装：#cd&x11perf-1.5
#./configure
#make install
安装完后会在x11perf-1.5里生成可运行文件x11perf。
3）运行：#x11perf -all
会弹出一个窗口，结果显示在终端，也可以在运行命令后加测试结果保存路径来保留测试记录，即#x11perf -all &/opt/x11perf-result.txt。
十、glxgears
glxgears：
1、打开终端，输入#glxinfo |grep rendering，敲回车，提示：direct rendering: Yes 表明启动正常；
2、在终端输入#glxgears，敲回车，弹出一个窗口，里面有3个转动的齿轮，并且终端每5秒显示出转动多少栅；
3、记录下FPS数字（每秒的帧速度）以鉴别3D加速效果（FPS越大越好）；
4、结果显示在终端，也可以在运行命令后加测试结果保存路径来保留测试记录，即#glxgears&/opt/glx-result.txt
十一、iperf
安装iperf：
#tar -zxvf iperf-2.0.4.tar.gz
#./configure；
#make install
运行iperf：
服务器终端：#iperf -s；
客户端终端：#iperf -c (serverip)-i 2 -f -t 86400
“-i 2”意思是每2秒钟输出一个值；
“-f”意思是默认以Mbit/s作单位；
“-t”设置运行时间，以秒为单位，跑压力24小时的话“-t 86400”，不加-t参数，默认输出5次值。
调优时在客户端终端加参数-M（设定TCP数据包的最大mtu值，参考&#），-l（缓冲区大小，默认是8KB,参考&#），-w（设定TCP窗口大小，默认是8KB，参考&#k）
可以在运行命令后加测试结果保存路径来保留测试记录，即#iperf-s &/opt/iperfserver-result.txt和#iperf -c (serverip)-i 2 -f -t 86400 &/opt/iperfclient-result.txt。
十二、netperf
安装：#tar -zxvf netperf-2.4.5.tar.
#cd netperf-2.4.5;
#./configure --build mips(alpha)
运行：2台机器网线直连，分别安装好netperf软件，分别设置好同一网段的IP地址，互相ping通。
1台机器作为服务器端，运行：#netserver；先运行服务器端，会提示打开xxx端口。
另一台机器作为客户端，运行：#netperf -HserverIP（即服务器端的IP地址） -l time（默认秒为单位），默认TCP批量传输，其他模式参数见netperf参数表格。
十三、linpack
linpack安装与运行：
#cp -rf mpich2-1.3.1.tar.gzhpl-2.0.tar.bz blas.gz /opt
#tar -zxvfmpich2-1.3.1.tar.gz
#cd mpich2-1.3.1
#./configure --prefix=/mpich--with-atomic-primitives=no --build=mips64el(双路龙芯需加入这一句)
#make install
#gzip -d blas.gz
#tar -xvf blas.tar
#vi make.inc
按“i”,修改FORTRAN= /mpich/bin/mpif77,和LOADER= /mpich/bin/mpif77，按Esc，按“：”，输入wq，敲回车。
#tar -zxvf hpl-2.0.tar.gz
#cd hpl-2.0/setup
#bash make_generic
#mv Make.UNKNOWN ../
#vi Make.UNKNOWN
按“i”,修改以下6行：TOPdir=/opt/hpl-2.0
MPdir= /mpich
LAdir= /opt/BLAS
LAlib= /opt/BLAS/blas_LINUX.a
CC= /mpich/bin/mpicc
LINKER= /mpich/bin/mpif77
按Esc，按“：”，输入wq，敲回车。
#make arch=UNKNOWN
#cd /opt/hpl-2.0/bin/UNKNOWN
#vi HPL.dat
修改Ns,NBs,Ps,Qs的值。
Ns的平方=总内存（Byte）*内存利用率（X86平台一般取80%，一般取10%、20%）/8；
NBs，X86平台一般取2个&#2，一般取32 64；
Ps尽可能设置为1；
Qs设置为CPU总线程数，FT1000CPU有64线程，则Qs=64。
运行：#cd/opt/hpl-2.0/bin/UNKNOWN
#/mpich/bin/mpirun -np 64(测试的线程数) ./xhpl
可以在运行命令后加上测试结果的保存路径来保留测试记录，即#/mpich/bin/mpirun -np 64(测试的线程数) ./xhpl&/opt/linpack-result.txt。
NF2160老化脚本：t.sh
cd /opt/hpl-2.0/bin/UNKNOWN/
for((i=1;i&=5;i++))
& /mpich/bin/mpirun -np 64 ./xhpl&/usr/201206lpk-test$i
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场当前位置：
测试探究SSD固态硬盘性能下降的谜题
测试探究SSD固态硬盘性能下降的谜题
来源： it168网站 日
众所周知，随使用时间的推移，SSD的性能会逐渐下降，特别是早期SSD产品更是如此，新的控制器通过各种技术有效缓解了这个问题。在这篇文章中，我们将执行一些企业级SSD基准测试，通过对比前后测试结果，加深对SSD性能下降的理解。
众所周知，随使用时间的推移，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空间浪费就很大（编者注：Intel X25-E的容量目前之后32GB和64GB两种），至于文件系统，当然选择了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()读取文件的性能。它打开一个文件，以记录长度将文件内容读取到用户空间的缓冲区中，重复这个操作，直到整个文件全部读入。
　　freread
　　这个测试和reread测试类似，但它使用的是fread()库函数，它读取最近打开的文件，因此可以使用文件系统或操作系统的缓冲区提高读取性能。
虽然还有其它测试选项，但这里列举的已经够多了基本上覆盖了大部分应用程序的访问模式。
对IOzone来说，系统规格是相当重要的，因为它们会影响到命令行选项。特别是系统内存容量是很重要的，因为它对缓存效率的影响是很大的，如果测试集大小足够小到以匹配文件系统/操作系统缓存(或部分)，结果可能会完全不一样。例如，在只有1GB内存的系统上和在有8GB内存的系统上运行相同大小的测试集，其结果会有很大的差异。
在这篇文章中，缓存的影响是有限的。如果运行非常大的测试集，并强制操作系统消除几乎所有缓存？缓存影响是不能完全消除的。减少缓存影响最好的办法是使文件比主内存更大，这里选择的文件大小是16GB，相当于主内存的两倍，我们是根据以往的经验和网上流传的一些说法选择的。
我们测试了四种记录大小：1MB、4MB、8MB和16MB，总文件大小为16GB，因此分别有1、条记录，执行测试的命令如下：
　　./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
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 Cu
这里的“-np”表示进程数量(本例中是4)，“-machinefile”指的是运行时使用的系统主机名列表(本例是一个./machinefile文件，包含了测试机器的主机名)，结果输出到一个名为metarates_disk.np_4.1.out的文件中，请自行理解文件的命名规则。
我们执行了三种不同的性能测试：
　　文件create和close速度(每秒的次数)。
　　文件stat速度(每秒stat操作次数)。
　　文件utime速度(每秒utime操作次数)。
I/O密集型压力测试过程
正如前面提到的，我们先在干净的磁盘上执行基准测试，然后执行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命令选项。
　　-np 4：表示进程数为4。
　　-machinefile ./machinefile：指定主机名列表的位置，由于我们是在单机上测试，因此只列出了本系统的主机名，每个测试对应一条，因此总共有4条记录。
　　./IOR：可执行文件的名称。
IOR的真正运行参数是放在可执行文件IOR之后的，参数解释如下：
　　-a POSIX：告诉IOR使用POSIX API(不是MPI-IO或其它API)。　　-b 64k：块大小，这里是64KB。　　-F：告诉IOR每个进程使用一个文件。　　-i 10：告诉IOR运行10次测试。　　-s 200000：告诉IOR段的数量，这里是200000。　　-t 4k：告诉IOR传输大小，这里是4KB。　　-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. 10 1 0 1 0 0 6
POSIX EXCEL
　　read 242.10 241.06 241.56 0.31 0.07 0.07 0.07 0.00 231. 10 1 0 1 0 0 6
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 IOzone重写吞吐量测试结果(KB/s)
从上图可以看出，在重写吞吐量基准测试中，记录大小为4MB时，“前”比“后”结果更快，但差距是很小的(约3.5%)，至于其它记录大小，压力测试前后的重写吞吐量性能差异都落在标准偏差范围内，两者之间的差距基本上可以忽略。
图4 IOzone读吞吐量测试结果(KB/s)
尽管我们看到的是“前”比“后”性能要快，但两者之间的差异均落在标准偏差范围内，因此也不能轻易说“前”比“后”性能要好。
图5 IOzone重读吞吐量测试结果(KB/s)
在这个测试中，“前”和“后”测试结果之间的差距也很小。
图6 IOzone随机读吞吐量测试结果(KB/s)
在这个测试中，我们真正看到了“前”和“后”测试之间的差距，从上图可以看出，“前”性能明显好于“后”性能，对于4MB、8MB和16MB记录大小，“前”结果比“后”结果要高出13-15%。
图7 IOzone随机写吞吐量测试结果(KB/s)
这些测试结果和随机读测试结果有点不一样，记录大小为4MB时，压力测试前的性能(前)比压力测试后(后)的性能要好得多，但在其它记录大小情况下，两者之间的差距是很小的，因此也不能轻易地说一个比另一个好。
测试结果：吞吐量结果（二）
图8 IOzone反向读吞吐量测试结果(KB/s)
从上图可以看出，三个较大记录大小的“前”性能明显好于“后”性能，差距大约在17-20%左右。
图9 IOzone记录重写吞吐量测试结果(KB/s)
在这个测试中，压力测试前后的性能表现旗鼓相当。
图10 IOzone跨越式读吞吐量测试结果(KB/s)
对于这个特殊的I/O模式，我们发现压力测试前的性能明显好于压力测试后的性能，对于较大的三个记录大小尤其如此，“前”结果比“后”结果要快22-23%左右。
图11 IOzone Fwrite吞吐量测试结果(KB/s)
在这个测试，压力测试前后的性能差距不明显，可以忽略。
图12 IOzone Frewrite吞吐量测试结果(KB/s)
和fwrite测试结果一样，压力测试前后的性能差距并不明显。
图13 IOzone Fread吞吐量测试结果(KB/s)
在这个测试中，虽然压力测试前后的性能存在一定的差距，但都落在标准偏差范围内，因此也不好说谁赢谁输。
图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 IOzone 写IOPS测试结果
压力测试前后写IOPS测试结果有些差距，记录大小为8KB时前后结果差距有点大，但标准偏差相互都很接近，因此总体来看性能不存在明显的差距。
图16 IOzone 读IOPS测试结果
在这个测试中，压力测试前后的性能差距很小，可以忽略。
图17 IOzone随机写IOPS测试结果
从上图可以看出，仅记录大小为32KB和64KB时，压力测试前后的性能存在明显的差距，记录大小为32KB是，“前”比“后”结果要高10.8%，记录大小为64KB时，“前”比“后”结果高8.7%。
图18 IOzone 随机读IOPS测试结果
在这个基准测试中，较小记录大小和较大记录大小压力测试前后的结果发生了有趣的变化，对于32KB和64KB记录大小，压力测试后的性能要明显好于压力测试前的性能，例如32KB记录大小，“后”比“前”高14.26%，对于64KB记录大小，“后”比“前”高12.6%。
对于IOPS测试，总体来看，压力测试前后的性能差距是很小的，但在随机IOPS测试中，我们发现压力测试前后的确存在一定的性能差距。
元数据测试结果
我们执行了三种元数据测试：文件open/close性能，文件stat性能和文件utime性能。
图19 Metarates元数据文件create/close测试结果(每秒的操作次数)
从上图可以看出，真正存在性能差距的是4个进程时，压力测试前比压力测试后的性能要好9%。
图20 Metarates元数据文件stat测试结果(每秒操作次数)
从上图可以看出，NP=1时，“后”比“前”性能好3.88%，NP=2时，“后”比“前”性能好6.58%，NP=4时好3.44%。
图21 Metarates元数据文件utime测试结果(每秒操作次数)
在这个测试中，压力测试前后虽然存在一定的性能差距，但都落在标准偏差范围内，因此不能说谁输谁赢。总的说来，元数据性能是“后”比“前”好。
总结：企业级SSD性能下降并不明显
本次基准测试的目的是使用支持TRIM的Linux内核测试一款企业级SSD（目前似乎还没有哪款企业级SSD宣称支持TRIM，编者注），通过I/O密集型测试前后的基准测试对比来分析性能下降的原因。
为了对比压力测试前后的性能，我们使用了三种类型的基准测试：吞吐量测试、IOPS测试和元数据测试。首先在全新的磁盘上执行基准测试，然后执行I/O密集型压力测试，最后再执行基准测试。测试所用的是一块英特尔X25-E SSD，CentOS 5.4操作系统，Linux内核2.6.34，并打了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硬盘会随时间推移速度变得越来越慢，读完本文后你应该打消这个疑虑了。
本文关键词：
IOzone相关文章
IOPS相关文章
X25-E相关文章
ext4相关文章
(没有帐户？)
使用第三方帐号登录:
台湾云计算协会（The Cloud Computing Association in Taiwan ）本周四宣布将开始支持Facebook发起的“开放
企业级硬盘相关随笔
企业级硬盘相关博客
企业级硬盘相关讨论组
企业级硬盘相关投票
企业级硬盘相关用户
Copyright& 1997-
CNET Networks 版权所有。
ZDNet 是CNET Networks公司注册服务商标。
中华人民共和国电信与信息服务业务经营许可证编号：京ICP证010391号 京ICP备号-159
京公网安备：}