服务器虚拟化对存储性能的影响分析

network

服务器虚拟化对存储性能的影响分析

H3C目前已经部署了Hyper-V、VMware、OVM、CAS等虚拟化产品，应用包括邮件、Notes、中间件、数据库、防病毒、文件服务等在内，近150个应用运行在约450台虚拟机上。虚拟化给企业节省了硬件成本，提高了资源利用率，方便管理员部署系统。但虚拟化性能损耗大、响应缓慢等问题也随之而来。本文专门针对虚拟机所挂载存储的性能进行了测试，希望通过此文能给大家提供一个参考，找到不同虚拟化产品与存储之间的结合点。

文/倪泽峰

虚拟化对存储系统性能影响的主要有5个因素：

- 虚拟化平台操作系统对存储的读写操作机制；

- 不同操作系统对存储的读写操作机制；

- 半虚拟化驱动与全软件模拟；

- Cache缓存的配置；

- 测试软件的压力机制及稳定性。

除此以外，HBA卡的型号，服务器和存储的连接模式，网线的类型都能影响存储的性能。

我们通过测试分析对比各虚拟化平台及物理机分别对IP SAN存储和FC SAN存储的性能影响，及在虚拟化平台下半虚拟化和全软件模拟的性能差异，虚拟化平台下Cache机制的不同对存储性能的影响。

一、 测试方法

本次测试重点关注存储的IOPS，IOPS (Input/Output Per Second)即每秒的读写次数，是衡量磁盘性能的主要指标之一。IOPS是指单位时间内系统能处理的I/O请求数量，一般以每秒处理的I/O请求数量为单位，I/O请求通常为读或写数据操作请求。随机读写频繁的应用，如OLTP(Online Transaction Processing)。对于存储的带宽则需多台客户端一起并行测试，故对测试环境拓扑的要求更为复杂，不利突出虚拟化对存储性能的影响，在测试过程中，为了减小各个环节的影响，测试采用直连的模式，在IP SAN存储中直接通过服务器的网卡连接存储设备，避免了中间环节以太网交换机对测试的影响，在FC SAN存储中直接通过服务器的HBA卡连接存储设备，避免了中间环节光纤交换机对测试的影响。

l Windows系统：采用SPC专业存储测试软件

SPC是专业的存储性能测试工具，得到业界存储厂商的认可，故在此测试中对Windows系统采用SPC软件进行测试。其中，SPC-1用于测试存储子系统在具有随机读写操作的同时进行查询更新操作等特征的应用环境中的性能表现，此类应用的代表有OLTP（联机事务处理）系统、数据库系统和邮件服务系统等，测试结果对IOPS特别敏感。

SPC-1测试工具由SPC官方发布，负责为ASU（Applications Storage Units）生成I/O请求，完成结果统计，并生成测试数据统计结果。

每个ASU的I/O流上可并发运行的实例的数目由BSU（Business Scaling Units）的数目指定。BSU在模型中用于模拟应用中的用户规模，一个BSU最多能模拟50个IOPS。BSU数目是测试的输入，通过调节BSU的数目来对I/O流量进行调节。

SPC-1要求I/O平均响应时间在30ms以内，因此若测试结束后平均响应时间小于30ms，那么该BSU可被认为是存储系统能达到的BSU数值，并得到相应的IOPS数值，在读写比例上，读占40%左右，写占60%左右，模拟了OLTP（联机事务处理）、数据库和邮件服务等应用的生产环境场景。

l Linux系统：采用FIO开源软件测试

FIO是一款Linux下开源的IO性能测试工具, 非常灵活，可以通过多线程或进程模拟各种IO操作，支持各种不同的I/O引擎。由于SPC License的影响，而且FIO是基于Linux下开源的工具，该软件作者也是Linux内核IO部分的开发者，故对Linux系统采用FIO开源软件进行测试。此次测试读写模式采用随机读和随机写的方式，单次IO大小设为8K，同spc测试工具，多线程数量为8，调用Linux自带异步IO模块Libaio。把Direct参数调为1，测试过程会绕过机器自带的Buffer，使测试结果更真实。

二、 测试方案

本次测试分析以VMware、Hyper-V和KVM为对象构建模拟环境，并采用专业的存储测试软件SPC和FIO工具进行测试。所测试的存储分别为一台FC存储和一台IP SAN存储。分析基于HP DL380 G5服务器为客户端，客观的模拟了生产环境的各个要素（IOPS、块大小、读写比例等），真实的反应了各虚拟化平台对存储的性能影响，本次测试也很好的反应了半虚拟化驱动在环境中的应用效果，突出了在不同Cache机制下对存储性能的影响（如表1所示）。

产品	产 品 版 本
VMware	VMware ESXi 5.1.0
Hyper-V	WindowsServe 2012 R2 Hyper-V
KVM	Red Hat Enterprise Linux 6.4 KVM
服务器	HP ProLiant DL380 G5，CPU Intel Xeon E5110 @1.6 GHZ 2*2核，内存8G， 2×146G 万转SAS硬盘做RAID1
虚拟机	4个vCPU，4G内存，OS Windows Server 2012和RHEL64
测试工具	FIO 2.1和 SPC

表1 虚拟化对存储性能影响的测试配置表

本次专项测试搭建的存储系统使用配置如表2所示：

存储类型	硬盘类型	硬盘转速(rpm)	硬盘数量(块)	硬盘大小(GB)	RAID级别
FC SAN	FC	15K	12	146	RAID10
IP SAN	SATA	7200	12	500	RAID10

表2 被测存储系统配置表

三、 测试数据

l Windows 2012平台

存储类型	虚拟化平台	IOPS	RAID级别	响应时间	容量
FC SAN存储	Native（非虚拟化 ）	2901.87	RAID10	30.55	100GB
	KVM	3801.24	RAID10	30.839	100GB
	VMware	3903.13	RAID10	30.944	100GB
	Hyper-V	2902.15	RAID10	30.11	100GB
IP SAN存储	Native（非虚拟化 ）	1598.48	RAID10	22.365	100GB
	VMware	1599.62	RAID10	28.553	100GB
	Hyper-V	1598.41	RAID10	23.518	100GB
	KVM	1584	RAID10	29.075	100GB

l Linux：RHEL64平台

存储类型	虚拟化平台	读写类型	IOPS	带宽	响应时间
FC SAN存储	Native（非虚拟化）	随机写	3507	28071KB/s	58.66
		随机读	3113	24916KB/s	65.5
	VMware	随机写	3503	28038KB/s	61.08
		随机读	4053	32436KB/s	55.06
	Hyper-V	随机写	3300	26415KB/s	64.58
		随机读	2088	16718KB/s	98.04
	KVM	随机写	3122	24990KB/s	69.75
		随机读	3117	24949KB/s	66.23
IP SAN存储	Native（非虚拟化）	随机写	1438	11520KB/s	143.08
		随机读	1190	9530KB/s	171.01
	VMware	随机写	1437	11508KB/s	144.32
		随机读	1188	9516.6KB/s	171.93
	Hyper-V	随机写	1436	11496KB/s	143.99
		随机读	1187	9507.3KB/s	171.87
	KVM	随机写	1433	11474KB/s	144.21
		随机读	1189	9524.7KB/s	171.79

四、 测试数据对比分析

1. FC SAN在Linux平台上对比

图1 在Linux平台下对FC SAN存储IOPS的比较

从图1可以看出，读IOPS在VMware平台上虚拟的Linux操作系统性能最优，甚至高于裸机性能的30%，高于最低性能平台Hyper-V的94%。写IOPS在各虚拟化平台上，VMware也是性能最好的产品，性能和裸机相近，总体差异不大。

图2 在Linux平台下对FC SAN存储延迟的比较

图2比较的是性能测试另一指标延迟，FIO测试工具体现的IO延迟基本上与IOPS成反比，IOPS越高，延迟越低，相反IOPS越低，延迟越高，故在延迟方面VMware也是最优。

2. FC SAN在Windows平台上对比

图3 Windows平台下对FC SAN存储IOPS的比较

3. 从图3可以看出，IOPS最好的虚拟化平台是VMware和KVM，SPC1测试软件本身定义了读写比例，在此IOPS值更能友好地体现应用整体性能。在延迟方面SPC1要求是测试结束后平均响应时间小于30ms，因此在这里不做比较。

4. IP SAN在Linux平台上对比

IP SAN存储性能测试的场景同FC SAN，测试工具同FC SAN，故能相对的反应出这两种不同类型存储性能的差异。

图4 在Linux平台下对IP SAN存储IOPS的比较

从图4的测试数据看出，IP SAN存储的性能对于不同虚拟化平台影响不大。

图5 在Linux平台下对IP SAN存储延迟的比较

如图5所示，从存储延迟方面的比较也说明了IP SAN存储的性能在不同虚拟化产品的差异不大。

5. IP SAN在Windows平台上对比

图6 Windows平台下对FC SAN存储IOPS的比较

从图6的测试数据看出，通过不同的测试工具SPC，IP SAN存储的性能对于不同虚拟化平台影响也不大，综合两种测试环境得出，IP SAN存储性能在不同虚拟化平台下的影响不大。

6. FC SAN在KVM虚拟化产品上不同配置的对比

相对VMware和Hyper-V，KVM开源产品更具灵活性，可以设置缓存机制及是否半虚拟化驱动，因此我们针对KVM产品进行了如下测试。

l 是否采用半虚拟化驱动

KVM是必须使用硬件虚拟化辅助技术（如Intel VT-x、AMD-V）的Hypervisor，在CPU运行效率方面有硬件支持，其效率是比较高的，在有Intel EPT特性支持的平台上，内存虚拟化的效率也较高。QEMU/KVM提供了全虚拟化环境，可以让客户机不经过任何修改就能运行在KVM环境中。不过，KVM在I/O虚拟化方面，传统的方式是使用QEMU纯软件的方式来模拟I/O设备，其效率并不非常高。在KVM中，可以在客户机中使用半虚拟化驱动（Paravirtualized Drivers，PV Drivers）来提高客户机的性能（特别是I/O性能）。目前，KVM中实现半虚拟化驱动的方式是采用了Virtio这个Linux上的设备驱动标准框架。

图7 半虚拟化驱动对读写IOPS的比较

从图7的测试数据看出，Virtio半虚拟化驱动的方式可以获得很好的I/O性能，比纯软件模拟高于4倍多，其性能几乎可以达到和Native（即：非虚拟化环境中的原生系统）差不多的I/O性能。所以，在使用KVM之时，如果宿主机内核和客户机都支持VirtIO的情况下，一般推荐使用Virtio达到更好的性能。当然，Virtio的也是有缺点的，它必须要客户机安装特定的Virtio驱动使其知道是运行在虚拟化环境中，且按照Virtio的规定格式进行数据传输，不过客户机中可能有一些老的Linux系统不支持Virtio和主流的Windows系统需要安装特定的驱动才支持Virtio。不过，较新的一些Linux发行版（如RHEL 6等）默认都将Virtio相关驱动编译为模块，可直接作为客户机使用Virtio，而且对于主流Windows系统都有对应的Virtio驱动程序可供下载使用。

图8 半虚拟化驱动对读写延迟的比较

从图8的测试数据看出，VirtIO半虚拟化驱动的方式可以获得很好的IO延迟，从另一个层面验证了半虚拟化驱动在KVM发挥的性格优势。

l 是否采用缓存机制

对于存储技术来说，数据写入到硬盘中，有多种针对硬盘缓存的写策略，其中常见的有Writethrough、Writeback及Nocache，而KVM虚拟的硬盘支持多种写策略。

? Writethrough

此模式先将数据写入Host Pagecache，等到数据落地之后，才算写完，而操作系统接收到硬盘返回来的已成功写入的信号之后，才会写下一段数据,但是Disk Write Cahce是关闭的，因此此cache模拟保证了数据的完整性。由于Host Pagecache是打开的，读性能对于此模拟相对可以，Disk Write是关闭的，对写的性能有影响。

? Writeback

此模式把Host Pagecache和Disk Write Cache都打开了，故IO性能是最优的，但是如果出现电源故障，数据是不被保护，因此此模拟只适合测试，不适合企业生产环境。

? Nocache

此模式把Host Pagecache关掉，但是把Disk Write Cache打开，由于写操作越过了Host Page Cache，直接到了Disk Write Cache，因此写性能是最佳的。此模拟下，如果发生电源故障，数据的完整性可以保证。由于关掉了pagecache，因此读性能比Write Through差，性能数据比较如图9所示。

图9 Cache机制对读写IOPS的比较

从图9的测试数据看出，Writeback的读性能是最好的，比Writethough高出100%，Writeback和Writethough的读性能相差不大，比Nocache高出29%。

图10 Cache机制对读写延迟的比较

从图10的测试数据看出Nocahe延迟和Wirtethough写延迟相对很低，原因是都避开了Host Pagecache。

五、 测试结论

根据本次测试结果，对被测存储系统的性能影响具体结论如下：

l 针对FC SUN存储，读IOPS在VMware平台上虚拟的Linux操作系统性能最优，甚至高于裸机性能的30%，高于最低性能平台Hyper-V的94%，写IOPS在各虚拟化平台上，VMware也是性能最好的产品，性能和裸机相近，但总体差异不大，虚拟的Windows操作系统中，VMware和KVM在IOPS上表现最好，高于裸机性能的53%.

l 针对IP SUN存储，由于网卡虚拟化对于各虚拟化厂商来说，已是非常成熟的技术，存储的读写性能在不同虚拟化平台下影响不大。

l 在虚拟化应用中，Cache机制对存储性能的影响起到了关键作用，考虑企业数据的完整性，建议使用Nocache作为KVM的缓存机制，既考虑了存储性能有兼顾了数据安全性。Virtio半虚拟化驱动的方式可以获得很好的I/O性能，比纯软件模拟高于4倍多，其性能几乎可以达到和Native（即：非虚拟化环境中的原生系统）差不多的I/O性能。所以，在使用KVM之时，如果宿主机内核和客户机都支持VirtIO的情况下，一般推荐使用Virtio达到更好的性能。

六、 结束语

未来虚拟化将在企业中应用逐渐广泛, 传统存储架构无法有效管理虚拟机产生的复杂随机性I/O，势必会消耗存储性能，存储虚拟化也随之成为了虚拟化存储问题的解决方案之一，重复数据删除与自动化精简配置等新技术的应用可以使存储虚拟化更高效，减少数据中心的开支。

network

回复 1# network

你的虚拟终端来数量、存储RAID形式等有自关，具体可以知看一下vmware官方文档，里面有计算公式道：

http://www.vmware.com/files/cn/pdf/view_storage_considerations.pdf

本回答由提问者推荐

network

SAS 15k理论值200个IOPS，10k理论值160个IOPS。
SATA 7.2k理论值75个IOPS，5.4k理论值大概60个IOPS.

network

回复 3# network
IOPS（Input/OutputOperations Per Second）是一个用于计算机存储设备（如硬盘（HDD）、固态硬盘（SSD）或存储区域网络（SAN））性能测试的量测方式，可以视为是每秒的读写次数。和其他性能测试一様，存储设备制造商提出的IOPS不保证就是实际应用下的性能。
IOPS可以用应用程序来量测，例如一开始由微软开发的Iometer，像IOzone及FIO也有类似功能，IOPS主要会用在服务器，以找到最佳的存储配置。
IOPS的数值会随系统配置而有很大的不同，依测试者在测试时的控制变因而异，控制变因包括读取及写入的比例、其中循序访问及随机存取的比例及配置方式、线程数量及访问队列深度，以及数据区块的大小。其他因素也会影响IOPS的结果，例如系统设置、存储设备的驱动程序、操作系统后台运行的作业等。若在测试固态硬盘时，是否先进行预调（preconditioning）机制也会影响IOPS的结果。 [1]

性能特性[url=]
编辑[/url]
最常量测的性能特性是随机存取及循序访问时的IOPS。循序访问是访问存储设备中相邻位置的数据，一般和较大的数据区块访问有关，例如128KB，随机存取是访问存储设备中非相邻位置的数据．一般访问的数据区块比较少，例如4KB。 [1]
最常见的性能特性如下：

量测	说明
总IOPS	每秒读写次数的总和（混合读取及写入测试）
随机读取IOPS	每秒平均的随机读取次数
随机写入IOPS	每秒平均的随机写入次数
循序读取IOPS	每秒平均的循序读取次数
循序写入IOPS	每秒平均的循序写入次数

对于硬盘或是其他类似的机电存储设备，其随机存取IOPS主要和存储设备的寻址时间有关，若是固态硬盘及其他固态电子设备，其随机存取IOPS主要和存储设备的内部控制器及记亿体接口速度有关。这两种设备的循序访问IOPS（尤其是访问大数据区块）一般会包括存储设备可以持续的最大带宽。
有些硬件会因为其队列深度增加而提升其性能，这多半是因为硬盘处理队列及重新排序（reordering）的先进控制器逻辑的结果，此逻辑一般称为标记命令队列（TCQ）或原生指令排序（NCQ）。企业档次的SATA硬盘，例如Western Digital Raptor及希捷的Barracuda NL配合深队列可以提升性能到100%。较常用在服务器的高端SCSI硬盘，一般性能有更大的提升。
传统的硬盘读取和写入的IOPS大约相同，而大部分闪存SSD的写入速度明显比读取慢很多，原因是无法写入一个之前写过的区域，会强制启动垃圾数据回收功能。因此硬件测试开始在测试IOPS性能时，分开测试写入和读取。
像Intel X25-E等较新的闪存SSD固态硬盘其IOPS会比传统的硬盘要高，在Xssist进行的一个测试中，用IOmeter软件，4KB随机存取，读取/写入比例为70/30，队列深度4，Intel X25-E 64GB G1的IOPS一开始有 10000 IOPs，在八分钟后快速掉到4000 IOPS，之后的42分钟持续的下降，自第50分钟起到第八小时之间，IOPS在3000至4000之间变化。即使第50分钟IOPS快速下降，X25-E的IOPS仍较传统硬盘要高。像OCZRevoDrive 3 x2 PCIe用SandForce控制器，其持续写入性能和读取速度大致相近。 [1]

一些IOPS的示例[url=]
编辑[/url]

硬盘驱动器
随机存取处理下，一些常见的IOPS平均值，计算方式是1/(寻址时间 + 回应时间) = IOPS： [1]

设备	形式	IOPS	接口	注解
7,200RPMSATA硬盘驱动器	硬盘驱动器	~75-100 IOPS	SATA 3Gbit/s
10,000 RPM SATA硬盘驱动器	硬盘驱动器	~125-150 IOPS	SATA 3 Gbit/s
10,000 rpmSAS硬盘驱动器	硬盘驱动器	~140 IOPS	SAS（串列SCSI）
15,000 rpmSAS硬盘驱动器	硬盘驱动器	~175-210 IOPS	SAS（串列SCSI）

固态设备

设备	形式	IOPS	接口	注解
英特尔Intel X25-M G2（MLC）	SSD	~8,600 IOPS	SATA 3 Gbit/s	英特尔的数据表声称在4KB数据的写入及读取时，分别有有6,600/8,600 IOPS (80GB/160GB版本)及35,000 IOPS的速度。
英特尔 Intel X25-E (SLC)	SSD	~5,000 IOPS	SATA 3 Gbit/s	英特尔数据表声称在写入和读取的速度为3,300 IOPS及35,000 IOPS。写入和读取混和时为5,000 IOPS。英特尔的X25-E G1比X25-M G2快了约三倍
G.SkillPhoenix Pro	SSD	~20,000 IOPS。	SATA 3 Gbit/s	SandForce-1200为基础的固态硬件，配合加强版的固件，最快可到50,000 IOPS，性能测试的结果是随机读取可到~25,000 IOPS，随机写入可到~15,000 IOPS。
OCZVertex 3	SSD	最高可到60,000 IOPS	SATA 6 Gbit/s	随机写入4KB (Aligned)
CorsairForce Series GT	SSD	最高可到85,000 IOPS	SATA 6 Gbit/s	240GB Drive，循序读取为555 MB/s，循序写入为525 MB/s。随机写入4KB (Aligned)

network

回复 4# network

详解数据库三个核心性能指标--TPS\QPS\IOPS

时间：2019-10-14 13:26:23  来源：  作者：

概述

今天主要介绍MySQL数据库，或者说所有数据库的三个关键性能指标：

• qps 每秒处理的查询数
• tps 每秒处理的事务数
• IOPS 每秒磁盘进行的I/O操作次数

---

一、TPS（适用innodb）

1、概念

Transactions Per Second（每秒传输的事物处理个数），即服务器每秒处理的事务数。

TPS包括一条消息入和一条消息出，加上一次用户数据库访问。（业务TPS = CAPS × 每个呼叫平均TPS）

TPS是软件测试结果的测量单位。一个事务是指一个客户机向服务器发送请求然后服务器做出反应的过程。客户机在发送请求时开始计时，收到服务器响应后结束计时，以此来计算使用的时间和完成的事务个数。

一般的，评价系统性能均以每秒钟完成的技术交易的数量来衡量。系统整体处理能力取决于处理能力最低模块的TPS值。

2、TPS计算

2.1、方法一

Com_commit = SHOW GLOBAL STATUS LIKE 'Com_commit';Com_rollback = SHOW GLOBAL STATUS LIKE 'Com_rollback';Uptime = SHOW GLOBAL STATUS LIKE 'Uptime';TPS=(Com_commit + Com_rollback)/Uptime

2.2、方法二

use information_schema;select VARIABLE_VALUE into @num_com from GLOBAL_STATUS where VARIABLE_NAME ='COM_COMMIT';select VARIABLE_VALUE into @num_roll from GLOBAL_STATUS where VARIABLE_NAME ='COM_ROLLBACK';select VARIABLE_VALUE into @uptime from GLOBAL_STATUS where VARIABLE_NAME ='UPTIME';select (@num_com+@num_roll)/@uptime;

---

二、QPS（同时适用与InnoDB和MyISAM 引擎 ）

1、概念

每秒查询率QPS是对一个特定的查询服务器在规定时间内所处理流量多少的衡量标准，在因特网上，作为域名系统服务器的机器的性能经常用每秒查询率来衡量。

对应fetches/sec，即每秒的响应请求数，也即是最大吞吐能力。

2、QPS计算

2.1、方法一

Questions = SHOW GLOBAL STATUS LIKE 'Questions';Uptime = SHOW GLOBAL STATUS LIKE 'Uptime';QPS=Questions/Uptime

2.2、方法二

use information_schema;select VARIABLE_VALUE into @num_queries from GLOBAL_STATUS where VARIABLE_NAME ='QUESTIONS';select VARIABLE_VALUE into @uptime from GLOBAL_STATUS where VARIABLE_NAME ='UPTIME';select @num_queries/@uptime;

---

三、IOPS

1、概念

IOPS (Input/Output Per Second)即每秒的输入输出量(或读写次数)，是衡量磁盘性能的主要指标之一。IOPS是指单位时间内系统能处理的I/O请求数量，一般以每秒处理的I/O请求数量为单位，I/O请求通常为读或写数据操作请求。随机读写频繁的应用，如OLTP(Online Transaction Processing)，IOPS是关键衡量指标。另一个重要指标是数据吞吐量(Throughput)，指单位时间内可以成功传输的数据数量。对于大量顺序读写的应用，如VOD(Video On Demand)，则更关注吞吐量指标。

传统磁盘本质上一种机械装置，如FC,SAS,SATA磁盘，转速通常为5400/7200/10K/15K rpm不等。影响磁盘的关键因素是磁盘服务时间，即磁盘完成一个I/O请求所花费的时间，它由寻道时间、旋转延迟和数据传输时间三部分构成。

寻道时间Tseek是指将读写磁头移动至正确的磁道上所需要的时间。寻道时间越短，I/O操作越快，目前磁盘的平均寻道时间一般在3-15ms。

旋转延迟Trotation是指盘片旋转将请求数据所在扇区移至读写磁头下方所需要的时间。旋转延迟取决于磁盘转速，通常使用磁盘旋转一周所需时间的1/2表示。比如，7200 rpm的磁盘平均旋转延迟大约为60*1000/7200/2 = 4.17ms，而转速为15000 rpm的磁盘其平均旋转延迟约为2ms。

数据传输时间Ttransfer是指完成传输所请求的数据所需要的时间，它取决于数据传输率，其值等于数据大小除以数据传输率。目前IDE/ATA能达到133MB/s，SATA II可达到300MB/s的接口数据传输率，数据传输时间通常远小于前两部分时间。

IOPS可细分为如下几个指标：

Toatal IOPS，混合读写和顺序随机I/O负载情况下的磁盘IOPS，这个与实际I/O情况最为相符，大多数应用关注此指标。

• Random Read IOPS，100%随机读负载情况下的IOPS。
• Random Write IOPS，100%随机写负载情况下的IOPS。
• Sequential Read IOPS，100%顺序负载读情况下的IOPS。
• Sequential Write IOPS，100%顺序写负载情况下的IOPS。

IOPS的测试benchmark工具主要有Iometer, IoZone, FIO等，可以综合用于测试磁盘在不同情形下的IOPS。对于应用系统，需要首先确定数据的负载特征，然后选择合理的IOPS指标进行测量和对比分析，据此选择合适的存储介质和软件系统。

2、IOPS计算

理论上可以计算出磁盘的最大IOPS，即IOPS = 1000 ms/ (Tseek + Troatation)，忽略数据传输时间。假设磁盘平均物理寻道时间为3ms, 磁盘转速为7200,10K,15K rpm，则磁盘IOPS理论最大值分别为，

IOPS = 1000 / (3 + 60000/7200/2) = 140

IOPS = 1000 / (3 + 60000/10000/2) = 167

IOPS = 1000 / (3 + 60000/15000/2) = 200

3、案例

需求：20TB存储空间同时满足4500 IOPS+RAID 5，我应该如何计算？RAID 5或者RAID 1/0的时候分别需要多少块硬盘？

首先需要知道I/O中读操作(Read)与写操作(Write)所占的百分比。然后通过下列公式，将主机的IOPS需求转换成硬盘实际IOPS负载：

假定4500 IOPS中读/写比是2:1，则不同RAID类型Drive IOPS要求分别如下：

RAID 1/0: (2/3)*4500 + 2*(1/3)*4500 = 6000 IOPSRAID 5: (2/3)*4500 + 4*(1/3)*4500 = 9000 IOPSRAID 6: (2/3)*4500 + 6*(1/3)*4500 = 12000 IOPS

再参照下表中不同类型硬盘单块IOPS参数，得出需要多少块硬盘：

假定选用FC 15K RPM硬盘，则：

RAID 1/0: 6000/180 = 34 块RAID 5: 9000/180 = 50 块RAID 6: 12000/180 = 67 块

注：实际情况下还需考虑Vault Drivers (共5块)以及Hot Spares (建议每30块硬盘一个)。

最后，如果选用600GB FC硬盘来实现20TB可用空间，则RAID 1/0需要78块，RAID 5需要42块。

network

回复 5# network
Oracle 11g 如何使用脚本测算存储IOPS、延时及IO？余毅

原创

  

Oracle数据库的I/O校准功能，可以评估存储子系统的性能，并确定I/O性能问题是否是由数据库或存储子系统引起的。不像其他外部的I/O校准工具发出的是顺序I/O读写，Oracle 的I/O随机读写是使用Oracle数据文件来访问存储介质的。因此，Oracle的I/O校准功能，产生的结果更接近实际数据库性能。

一.
I/O校准的准备条件

1. 用户必须具有sysdba权限。

2. Timed_statistics参数必须设为true，异步IO必须打开。

ps：假设使用文件系统，可将FILESYSTEMIO_OPTIONS参数设成SETALL打开异步IO。可以执行如下sql查看异步IO是否打开：

3. 只有一个I/O校准同时在一个数据库实例进行。

二 .运行IO校对

Oracle数据库的I/O校准功能是使用DBMS_RESOURCE_MANAGER.CALIBRATE_IO存储过程访问的，该存储过程可以模拟出一系列密集的只读工作量，针对数据文件产生1M的随机IO，从而能确定最大IOPS（每秒I / O请求）和MBPS（每秒M单位的IO）。

使用DBMS_RESOURCE_MANAGER.CALIBRATE_I存储过程，该过程模拟产生数据块大小的随机读写（默认为8k），其会针对所有实例的所有数据文件都进行测试。这一步输出包括了最大的IOPS，且输出参数为max_iops。且actual_latency输出参数提供了这个库的平均延迟。我们也可以通过max_latency参数手工指定目标延迟（以毫秒为单位的数据库块大小的IO请求的最大容忍延迟，一般IO平均等待在10ms左右是良好的表现，远大于这个数字说明IO负载过高了）。输入参数num_physical_disks用于指定数据库存储所用物理磁盘数。

▲存储过程如下：

▲执行存储过程：

三.   需要注意点

• IO校准只是针对数据库使用同一个存储子系统情况，如果一个库横跨了多个底层存储子系统，模拟将会失败。
• 对于RAC，确保所有实例的校准跨节点的存储子系统都已打开，并且其负载是针对所有实例的。
• num_physical_disks 参数是可选的，这个参数越符合实际底层存储情况，性能将越好。
• 在IO校对过程中，可通过V$IO_CALIBRATION_STATUS视图查询校对的状态，在成功后，可在DBA_RSRC_IO_CALIBRATE视图中查看结果。

• Max_pmbps 表示max MB/秒 large IO req for single process。结合OS ，sar -b 5 100 可以看到如下图所示数据，通过Oracle生成大量的IO操作，能判断存储的极限。

Tps：表示I/O设备每秒的I/O传送次数，传送指的是一次I/O请求。

这样我们在测试数据性能时会更方便简单，也更有真实性。

其实这个功能不止可以做IO测试，配上Oracle 11g的resource manager(RM)，可以提供强大的决策能力，也就是说通过RM，我们可以判断用户资源组对IO的使用情况，比如某个应用IO使用量达到10000M、IOPS过大或者IO使用过多等，都有一系列的解决措施，资源转移，切换，甚至kill掉等。

network

回复 6# network

为了正确的配置数据库的存储设备，必须了解数据库的性能需求。

数据库的io类型
1 IO请求主要是单个块还是多个块
   数据库将发出多个IO请求：并行查询，查询大数据量的表扫描，直接数据装
   载，备份恢复。一般来说，OLTP主要是单个IO请求，DSS数据仓库是多个IO请
   求。
2 平均和峰值的IOPS是多少? 写占多少百分比 --可以通过v$sysstat及iostat查看;写占总的iops比率
3 平均和峰值的MBPS是多少？写占多少百分比。--平时与峰值,写占总的mbps比率

如果你的数据库IO请求主要是单个块，那就关注IOPS，
如果数据库IO请求主要是多个块，那就关注MBPS。

4,
也可以从awr报表中得到这些数据。
Instance Activity Stats            DB/Inst: DBS108A/dbs108a  Snaps: 8881-8882

-> Ordered by statistic name                                                   
                                                                              
Statistic                                     Total     per Second     per Trans
-------------------------------- ------------------ -------------- -------------
...
physical read total IO requests              27,791           15.7          38.7   --每秒总的读iops
physical read total bytes               319,881,216      180,368.5     444,897.4   --每秒读的数据大小
physical read total multi block                 115            0.1           0.2
...
physical write total IO requests              4,278            2.4           6.0  --同上
physical write total bytes               49,528,320       27,927.1      68,885.0
physical write total multi block                 22            0.0           0.0

测试方法：
1,用压力测试工具比如orion或ipzone或其它工具，模拟数据库不同的io请求类型：
   混合读写，纯随机读写，纯顺序读写；
2,查看上述不同io请求类型的iops及mbps(主要是平均及峰值，读写比率)
3,结合iostat的await平均io等待时间及%util io的使用率，可知不同磁盘（可能是1个或多个disk）的iops，平均io wait时间及io使用率
   及mbps
   
4,测试存储的io性能就是用压力测试工具,一直把iostat的%util使用率接近100%,查看对应的峰值iops及平均io等待时间
   这样就计算出来了存储的io性能；
   用这个与oracle io（用awr或v$systat)对比oracle io与存储io，是否匹配，可能为：
   存储io相当猛，够orace io用了
   或者存储io不足，不够oracle io用了
   这时最简单的解决方法：添加存储的磁盘
   其次重新规划存储的raid
   最后如不能扩展存储，修改oracle前台应用及调整oracle性能
   
5，通过db file sequential read可知单块读io的响应时间,用此值与iostat的svctm:   平均每次设备I/O操作的服务时间 (毫秒) 进行对
   比，如果小于后者，说明存储没问题，去查ORACLE;否则说明存储IO不足了；就是存储有问题了
   
   db file scattted read同上理，它是多块读的io响应时间
   
   
其它处理途径：

  1，响应时间+IOPS 就说明了系统的当前io状况啊,响应时间在 10ms 左右能达到的最大iops 能力，
     是系统io能力的一个最重要指标。

  2,衡量系统io能力，我们也是关注的高峰期一段时间内稳定运行的状况
  
  
  3,一个random IO的理论时间是：
       7ms =  4-5ms(磁盘平均寻道时间）+ 2ms (传输时间) + 一些其它的消耗
       如果不考虑file system cache hit(raw device/direct IO)  以及storage cache hit , 同时没
       有磁盘竞争，那么，db file sequntial read的时间就会是 7ms左右.
     

network

回复 7# network
什么样的存储引擎，让Oracle数据库性能100%增长？

青云QingCloud


云计算服务提供商




​关注她
1 人赞同了该文章

数据正进一步凸显其价值，越来越多企业开始意识到数据对业务的强大驱动力，希望收集更多数据并利用新的数据分析技术释放其中的价值，这需要企业 IT 提供更好的支撑，但传统基于 IOE（即以 IBM 小机、Oracle 数据库和 EMC 存储为代表的关键业务系统架构）方式构建的企业数据中心已经很难适应数字化时代对 IT 的要求。

于是，在 2011 年前后，业界掀起“去 IOE ”风暴：用开放标准的 x86 硬件和开源软件去替代传统封闭的 IT 软硬件。从过去几年的实践来看，Oracle 数据库目前仍是企业用户的首选，但承载 Oracle 等关键业务数据库的基石已经逐渐被x86和基于闪存的新一代存储所替代。

1、去 I、E 背后：x86 与闪存的力量

经过十几年的发展，x86 平台的计算性能和 RAS 特性（Reliability, Availability and Serviceability，可靠性、可用性与可维护性）都获得极高的成就，已经不弱于甚至超过了以 IBM Power 为代表的小机。而经过最近几年的实践，x86 平台已经逐步取代了传统小机。

E 也正在被基于 x86+ 全闪存配置的 Server SAN 所替代。在 SATA/SAS SSD 盛行的时代，与高端 SAN 相比，Server SAN 可能性能还有不足之处。

但随着 NVMe SSD 和支持 RDMA 技术的 25GbE 技术的普及，Server SAN 全面替代传统 SAN 存储已经成为可能。

NVMe SSD 的普及能够给创新型 SDS 方案提供商带来弯道超车的机会，由于传统 SAN 的可靠性设计需要双端口存储介质来实现，尽管 NVMe SSD 也支持双端口配置，但这意味着牺牲性能。

而采用分布式架构、利用多副本数据保护机制的 Server SAN 则无此烦恼，也就是说利用 NVMe SSD，Server SAN 的性能将有可能超越传统 SAN 存储。

同时，传统 SAN 所擅长的纵向扩展（Scale up）方式在 NVMe SSD 时代几乎很难派上用场（只能提升容量），而其多个控制器之间需要专用物理通路的设计，意味着横向扩展（Scale out）能力有限，这也是为何大多数高端存储控制器通常最大支持 8 个的原因之一。

“去 IOE”中的核心是“O”，但 Oracle 去 I、E 的尝试比所谓的“去 IOE”更早。

Oracle 在 2008 年推出了基于 x86 服务器的数据库一体机 Exadata，并从第二代开始采用服务器内置的 PCIe SSD 替代 SAN 存储。在 NVMe 规范成熟之后，Oracle Exadata 率先更新为 NVMe SSD。

Oracle Exadata X7-2 硬件配置，最小 2 数据库服务器+3 存储服务器配置，存储服务器均支持混合及全闪两种配置，数据库服务器支持最新的 25GbE，存储网络依旧使用 InfiniBand

Oracle Exadata 使用 InfiniBand 的主要原因在于其 RDMA 技术能够带来极低的延迟，有助于发挥 NVMe SSD 的优势。

最新一代的 25Gb/s 以太网技术也将 RDMA（即 RoCE 或 iWARP）作为标配，这将极大地提升 Server SAN 的性能。并且，在 25GbE 性能不满足需求的情况下，其也可以很便捷地升级到 100Gb/s 以太网。

8K 尺寸数据块是数据库类应用最常见的块大小，在使用支持 RDMA 技术的 100GbE 网络下，相比于 10GbE iSCSI，其有 20 倍的性能提升

青云QingCloud 的分布式块存储 NeonSAN 正是利用 NVMe SSD+25GbE 的组合，提供了极高的性能，并有效控制 I/O 延迟，这在上一篇文章中已经介绍过，在本文中，E 企研究院将构建贴近真实的数据库环境，以此评估 NeonSAN 在关键应用环境中的性能表现。

2、支撑关键应用 性能线性增长

E 企研究院根据企业关键应用的特点，使用 x86 服务器、Intel NVMe SSD 和 25GbE 构建了 Oracle RAC 数据库环境，用以评估青云 NeonSAN 在 OLTP 中的性能表现。

E 企研究院评估青云QingStor™ NeonSAN 性能所构建的 Oracle RAC 架构及组件

在此测试环境中，E 企研究院使用 2 台配备两颗 Intel Xeon E5-2698 v4 处理器的双路服务器构建 2 节点的 Oracle RAC 数据库应用环境，并安装 Oracle 12c 数据库软件（包括 Grid 和 Database）。

使用三台配备两颗 Intel Xeon SP Gold 6140 处理器的双路服务器作为 NeonSAN 存储节点，每节点上使用 4 片 8TB 容量的 Intel DC P4510 SSD 作为数据存储。

Intel DC P4510 SSD 是 Intel 最新发布的采用 3D NAND 技术的 SSD 和新一代的闪存控制器的 SSD 家族，其最大容量可到 8TB，结合企业数据中心优化的固件，能够给企业关键应用存储带来极高的性能和稳定性。

3、基准性能测试：摸底 NeonSAN

在进行正式测试之前，E 企研究院先对 QingStor™ NeonSAN 的基准性能进行测试，以检验其是否正确安装，获得的测试结果也为后续 Oracle RAC 数据库性能测试提供参考。

基准性能测试采用 4K 和 8K 两种尺寸的数据块进行随机读写测试，4K 的随机读写性能是业界用于评估存储性能的事实标准之一，8K 则是数据库类应用的常见数据块大小。

同时，分布式应用已经成为企业 IT 的主流架构，E 企研究院也考量了 NeonSAN 在分布式环境下的性能表现，如下图所示：

QingStor™ NeonSAN 在分布式环境下，4K、8K 随机读写 IOPS 与平均响应时间对比

QingStor™ NeonSAN 的 4K、8K 随机读写性能。从测试结果来看，在单台客户端下发压力情况下，4K 与 8K 随机读写性能都能接近或超过 10 万 IOPS，且平均响应时间在 0.5~0.8 ms 之间，具有不错的性能；

而在 2 台客户端并发压力下，其 4K 随机读写性能分别达到了 18.5 万和 13.6 万 IOPS，而 8K 随机读写性能也分达到了 18.6 万和 11.7 万 IOPS，相比单一客户端下，性能至少提升了 50%，而延迟增长却并不明显，仍保持较低水平。

同时，E 企研究院还评估了 NeonSAN 在多个存储卷下的性能增长情况，结果如下图：

在单个压力客户端（图上）和 2 个压力客户端（图下）测试环境中，QingStor™ NeonSAN 分别供应多个（1~4个）存储卷下的性能（IOPS）和响应时间（Latency，ms）表现

随着 NeonSAN 卷数量的增加，其性能线性增长，而平均响应时间的增长并不明显。

• 在单台客户端性能测试中，在配置 4 个 NeonSAN 卷时，4K 随机读写和 8K 随机读性能均在 30 万 IOPS 左右，8K 随机写性能则能超过 25 万 IOPS，平均响应时间则均控制在 1 ms 以内；
• 在 2 台客户端并发压力下，4K 随机读写性能分别达到了 62 万和 52 万 IOPS，8K 随机读写性能则分别超过了 47 万和 42 万 IOPS

4、Oracle RAC 测试，直面关键应用

基准性能测试只能反应存储系统的性能表现，上述测试结果表明 QingStor™ NeonSAN 已经安装正常，可以接入已经构建好的 Oracle RAC 数据库应用环境中。

但需要注意的是，在进行 Oracle RAC 数据库测试时，衡量的是包括 Oracle 数据库服务器、测试环境网络以及 NeonSAN 存储的综合性能表现，这三者任意子系统出现瓶颈，都会影响测试性能。

所以在正式测试之前，还需确认其中某些子系统的瓶颈，以明确可能影响 Oracle RAC 数据库性能的因素。E 企研究院利用 Oracle 数据库内嵌的一组命令来检验接入 Oracle RAC 环境后的 QingStor™ NeonSAN 性能。

与之前基准性能测试不同的是，这一项测试是基于 RDBMS 层的测试，其通过模拟 Oracle 数据库的数据访问特点来对后端 NeonSAN 存储进行评估。上图显示在配置 4 个 NeonSAN 存储卷后获得最大接近 35 万 IOPS，然后即使再添加 NeonSAN 存储，其性能几乎不变。而且顺序带宽则在 5 个 NeonSAN 卷时获得最高 3.3GB/s 吞吐量。

通过上述测试表现，在接入 2 节点的 Oracle RAC 环境之后，NeonSAN 在提供 4 个存储卷时获得最大随机读取性能。

因此，根据这一结果，E 企研究院为 Oracle RAC 数据库环境共分配 4 个 1TB 容量的存储卷，分别测试其在 1~4 个卷下的 Oracle 数据库性能表现，具体如下图：

在 Oracle RAC 数据库测试中，在配置 3 个卷作为 Oracle 数据库存储时，获得超过 165 万 TPM（TransactionsPer Minute，每分钟事务处理数），但再增加一个 NeonSAN 存储卷，数据库性能并没有增加，这意味着在 3 个 NeonSAN 卷时，Oracle RAC 应用的其他子系统已经出现瓶颈，导致尽管存储性能增加，但应用性能并没有增加。

结合上一个测试结果，此时瓶颈可能出现在计算方面，即 Oracle 数据库服务器的计算能力达到瓶颈。

通过监控画面可以看到，Oracle 服务器的 CPU 平均利用率已经超过 75%。结合以往 E 企研究院的测试经验来看，通常情况下，服务器 CPU 利用率超过 70% 就意味着已经达到最佳计算性能，即使再增加负载，CPU 占用率可能会进一步提升，但就应用来看，其性能并没有增加，反而延迟可能会出现不利影响。

因此，从测试结果来看，在配备 3 个 NeonSAN 卷做 Oracle 数据库存储时，整个 Oracle RAC 环境就已经达到最高性能，而在此环境中，Oracle 服务器配备的是 Intel Xeon E5-2698 v4 处理器，要提升计算性能就只能更换到最新一代 XeonSP 系列中的顶级处理器，或者使用配备更多 CPU 的四路及以上服务器。

即使受到 Oracle 数据库服务器计算性能的影响，在此 Oracle RAC 数据库环境中，也取得了超过 165 万 TPM 的性能，即每分钟能够完成超过 165 万笔事务处理，这之中包括新增商品的添加、用户的浏览、订单的处理、修改以及订单查询、追踪等等常见操作。

平均到每秒的事务处理量为 3 万笔，且每笔事务处理的响应时间不超过 15 ms。

对于企业核心数据库而言，NeonSAN 不仅具有超高的性能，同时还具备极低的延迟，能够为需求苛刻的关键业务应用提供强有力的支撑。

每分钟 165 万事务处理量意味着什么？E 企研究院收集了目前较为热门的相关行业或新秀公司，根据其公开资料/数据整理，以与 NeonSAN 的 Oracle RAC 数据库性能对比，具体如下图所示：

常见应用App平均日订单量一览

虽然上图列出的订单量与数据库性能之间并不能划等号，一笔订单背后可能会有包括用户登录、用户信息修改、产生订单以及查询等多个操作，但仍能提供部分参考建议。比如据国家邮政局的最新统计数据显示，今年（2018年）前 4 个月全国快递业务量累计完成 136.7 亿件，平均到每天的快递业务量约为 1.14 亿件，按 8 小时计算，相当于每分钟会产生 23.75 万件快递，相当于 23.75 万笔订单，每个订单背后按 5 个数据库操作计算（即 1 订单需要 5 数据库性能作为支撑），那么大约需要 120 万的数据库性能，即 120 万 TPM。

而通过 E 企研究院搜集的数据简单计算的话，三节点（全 NVMe SSD+25GbE）配置的 NeonSAN 存储集群能支撑 Oracle RAC 数据库达到 165 万 TPM 性能，均能支撑上述应用数据库所需的存储性能，并有富余，可应对更高的业务峰值。

尽管因为具体到应用可能有不同的流程，会对后端存储产生不同程度的性能需求。但 E 企研究院认为，QingStor™ NeonSAN 完全有能力满足绝大部分企业应用对块存储性能的需求。

经 E 企研究院的测试表明，QingStor™ NeonSAN 不仅是一款优秀的 Server SAN 产品，符合 SDS（Software Define Storage，软件定义存储）的软硬件解耦、高可用、高可靠、弹性以及无厂商锁定等特点，同时借助最新的 NVMe SSD+25GbE 网络技术，能够提供极高的性能和极低的 I/O 响应时间，完全有能力满足企业关键应用负载所需的 RAS 特性和苛刻性能需求，助力企业向混合云迈进，为数字化转型奠定坚实基础。

5、某保险企业借助 NeonSAN 打造核心业务存储引擎

区块链，人工智能，大数据等技术的迅猛发展给互联网保险带来消费场景、产品形态和营销方式三大维度的颠覆，推动互联网保险向新技术密集型经营模式转型。

在互联网保险业务中，IT 系统已经深入到产品开发、销售、服务等流程的各个环节，成为业务发展的核心驱动力，需要具备高效的业务支撑能力与高投资回报率。

某保险企业自开展互联网业务以来，在线保险业务年均增长 100% 以上，原有数据库一体机的物理硬件资源趋于饱和，不再支持扩容与升级。

为了匹配将来的业务发展，该保险企业决定采用数据库自 Oralce 一体机向 x86 平台迁移的方案：将 Oralce RAC 数据库迁移到物理机，使用 NeonSAN 集群作为后端存储，提供数据库支持服务，配置三副本的数据保护机制。

客户收益

• 经过业务场景实测，基于 NeonSAN 的复杂视图查询响应时间从 20 分钟以上缩小到 2 分钟，精算准备金复杂 SQL 执行效率从分钟级缩小到秒级，实现效率 100% 的提升，可确保所有类型的数据处理都能够实现卓越的性能。更快的查询速度和更快的报表运行速度，帮助企业推动业务决策的制定、提高准确度并获得高品质成果。
• NeonSAN 为最高级别的可用性奠定坚实的存储平台，可避免组件故障、网络故障或者人为错误造成的业务中断现象。与 Oracle RAC 搭配，应用程序和数据可实现最长的正常运行时间，让客户安枕无忧。

• NeonSAN 分布式架构，使存储扩容时间从几个月提升至几天，提升速度高达 10 倍，有效满足业务数据量激增的扩容需求，推动业务系统的平滑快速地发展。

network

https://zhuanlan.zhihu.com/p/43134300

network

回复 9# network

机械硬盘的连续读写性很好， 但随机读写性能很差。这是因为磁头移动至正确的磁道上需要时间，随机读写时，磁头不停的移动，时间都花在了磁头寻道上，所以性能不高。 如下图：

在存储小文件(图片)、OLTP数据库应用时，随机读写性能（IOPS）是最重要指标。
学习它，有助于我们分析存储系统的性能互瓶颈。
下面我们来认识随机读写性能指标–IOPS（每秒的输入输出次数）。

磁盘性能指标–IOPS    IOPS (Input/Output Per Second)即每秒的输入输出量(或读写次数)，是衡量磁盘性能的主要指标之一。IOPS是指单位时间内系统能处理的I/O请求数量，一般以每秒处理的I/O请求数量为单位，I/O请求通常为读或写数据操作请求。随机读写频繁的应用，如小文件存储(图片)、OLTP数据库、邮件服务器，关注随机读写性能，IOPS是关键衡量指标。顺序读写频繁的应用，传输大量连续数据，如电视台的视频编辑，视频点播VOD(Video On Demand)，关注连续读写性能。数据吞吐量是关键衡量指标。

• 1
• 2
• 3
• 4
• 5

IOPS和数据吞吐量适用于不同的场合：
读取10000个1KB文件，用时10秒 Throught(吞吐量)=1MB/s ，IOPS=1000 追求IOPS
读取1个10MB文件，用时0.2秒 Throught(吞吐量)=50MB/s, IOPS=5 追求吞吐量

磁盘服务时间

传统磁盘本质上一种机械装置，如FC, SAS, SATA磁盘，转速通常为5400/7200/10K/15K rpm不等。影响磁盘的关键因素是磁盘服务时间，即磁盘完成一个I/O请求所花费的时间，它由寻道时间、旋转延迟和数据传输时间三部分构成。

寻道时间 Tseek是指将读写磁头移动至正确的磁道上所需要的时间。寻道时间越短，I/O操作越快，目前磁盘的平均寻道时间一般在3－15ms。
旋转延迟 Trotation是指盘片旋转将请求数据所在扇区移至读写磁头下方所需要的时间。旋转延迟取决于磁盘转速，通常使用磁盘旋转一周所需时间的1/2表示。比如，7200 rpm的磁盘平均旋转延迟大约为60*1000/7200/2 = 4.17ms，而转速为15000 rpm的磁盘其平均旋转延迟为2ms。
数据传输时间 Ttransfer是指完成传输所请求的数据所需要的时间，它取决于数据传输率，其值等于数据大小除以数据传输率。目前IDE/ATA能达到133MB/s，SATA II可达到300MB/s的接口数据传输率，数据传输时间通常远小于前两部分消耗时间。简单计算时可忽略。

常见磁盘平均物理寻道时间为：
7200转/分的STAT硬盘平均物理寻道时间是9ms
10000转/分的STAT硬盘平均物理寻道时间是6ms
15000转/分的SAS硬盘平均物理寻道时间是4ms

常见硬盘的旋转延迟时间为：
7200 rpm的磁盘平均旋转延迟大约为60*1000/7200/2 = 4.17ms
10000 rpm的磁盘平均旋转延迟大约为60*1000/10000/2 = 3ms，
15000 rpm的磁盘其平均旋转延迟约为60*1000/15000/2 = 2ms。

最大IOPS的理论计算方法

IOPS = 1000 ms/ (寻道时间 + 旋转延迟)。可以忽略数据传输时间。

7200 rpm的磁盘 IOPS = 1000 / (9 + 4.17) = 76 IOPS
10000 rpm的磁盘IOPS = 1000 / (6+ 3) = 111 IOPS
15000 rpm的磁盘IOPS = 1000 / (4 + 2) = 166 IOPS

影响测试的因素

实际测量中，IOPS数值会受到很多因素的影响，包括I/O负载特征(读写比例，顺序和随机，工作线程数，队列深度，数据记录大小)、系统配置、操作系统、磁盘驱动等等。因此对比测量磁盘IOPS时，必须在同样的测试基准下进行，即便如此也会产生一定的随机不确定性。

队列深度说明

NCQ、SCSI TCQ、PATA TCQ和SATA TCQ技术解析是一种命令排序技术，一把喂给设备更多的IO请求，让电梯算法和设备有机会来安排合并以及内部并行处理，提高总体效率。

• 1

SCSI TCQ的队列深度支持256级
ATA TCQ的队列深度支持32级 （需要8M以上的缓存）
NCQ最高可以支持命令深度级数为32级，NCQ可以最多对32个命令指令进行排序。
大多数的软件都是属于同步I/O软件，也就是说程序的一次I/O要等到上次I/O操作的完成后才进行，这样在硬盘中同时可能仅只有一个命令，也是无法发挥这个技术的优势，这时队列深度为1。
随着Intel的超线程技术的普及和应用环境的多任务化，以及异步I/O软件的大量涌现。这项技术可以被应用到了，实际队列深度的增加代表着性能的提高。
在测试时，队列深度为1是主要指标，大多数时候都参考1就可以。实际运行时队列深度也一般不会超过4.

IOPS可细分为如下几个指标：

数据量为n字节，队列深度为k时，随机读取的IOPS
数据量为n字节，队列深度为k时，随机写入的IOPS

IOPS的测试benchmark工具     IOPS的测试benchmark工具主要有Iometer, IoZone, FIO等，可以综合用于测试磁盘在不同情形下的IOPS。对于应用系统，需要首先确定数据的负载特征，然后选择合理的IOPS指标进行测量和对比分析，据此选择合适的存储介质和软件系统。

• 1