如何合理评估服务器托管的费用及存储所需的IOPS
一、引言
在当今数字化时代，服务器托管已成为企业运营不可或缺的一部分。
企业在选择服务器托管服务时，除了关注服务质量和技术支持外，费用也是一个非常重要的考虑因素。
如何合理评估服务器托管的费用以及存储所需的IOPS（输入/输出操作每秒）成为了企业在决策过程中需要关注的关键问题。
本文将为您详细解析这一问题。
二、服务器托管费用的评估
1. 需求分析：企业需要明确自身业务需求，包括服务器规模、带宽需求、存储空间等。不同的业务需求将决定不同的托管方案，进而产生不同的费用。
2. 服务内容：服务器托管费用通常包括基础设施费用、带宽费用、IP地址费用等。企业需要了解每一项费用的具体内容和标准，以便做出合理的预算。
3. 市场调研：了解市场行情，对比不同服务商的报价和服务内容，选择性价比高的服务商。
4. 合同条款：在签订合同前，务必仔细阅读合同条款，了解是否有隐藏费用，确保自身权益。
三、存储所需的IOPS评估
1. IOPS概念：IOPS是输入/输出操作每秒的缩写，是衡量存储系统性能的重要指标。企业在评估存储需求时，需要考虑IOPS的大小，以确保系统能够应对日常的读写操作。
2. 业务需求：根据企业业务类型和需求，评估所需的IOPS大小。例如，数据库服务器的IOPS需求通常较高，而静态网站服务器的需求相对较低。
3. 存储类型：不同类型的存储系统具有不同的IOPS性能。企业在选择存储系统时，需要根据业务需求选择合适的存储类型，如固态硬盘（SSD）、混合存储等。
4. 测试与评估：在实际部署前，对存储系统进行测试与评估，以确保其满足企业业务需求。通过测试，可以了解存储系统的实际IOPS性能，进而调整和优化系统配置。
四、如何平衡费用与性能
1. 制定预算：企业在评估服务器托管费用和存储需求时，需要制定合理的预算。根据企业业务规模和需求，确定合适的预算范围。
2. 性价比评估：在选择服务器托管服务商和存储系统时，企业需要综合考虑性价比。不仅要关注价格，还要考虑服务质量、技术支持、稳定性等因素。
3. 长期合作：与优质的服务商建立长期合作关系，可以获得更优惠的价格和更好的服务。长期合作还可以帮助企业更好地规划和管理IT资源。
4. 灵活调整：随着企业业务的发展，托管需求和存储需求可能会发生变化。企业需要具备灵活调整的能力，以适应业务变化。
五、其他注意事项
1. 服务商信誉：选择有良好信誉的服务器托管服务商和存储设备供应商，可以保证企业的数据安全和服务质量。
2. 合同细节：在签订合同前，务必仔细阅读合同细节，了解各项条款和条件，确保自身权益。
3. 风险评估：在决策过程中，进行风险评估是非常必要的。企业需要评估潜在的风险因素，并制定相应的应对策略。
4. 咨询专家意见：在评估服务器托管费用和存储需求时，可以咨询专家意见，以获得更专业的建议和指导。
六、结语
合理评估服务器托管的费用以及存储所需的IOPS是企业决策过程中的重要环节。
企业需要关注自身业务需求、市场情况、合同条款等多方面因素，制定合适的预算和方案。
通过合理的评估和选择，企业可以获得性价比高的服务器托管服务和存储系统，为企业的业务发展提供有力的支持。
如何测试云硬盘
问题UOS公有云开放以来，一些用户反应用dd命令测试出来的1TB云硬盘的吞吐率(MBPS)只有128MB/s，而不是我们SLA保证的170MB /s ，这是为什么？下面我会简单介绍如何测试硬盘，RAID，SAN，SSD，云硬盘等，然后再来回答上面的问题。
测试前提我们在进行测试时，都会分清楚:测试对象：要区分硬盘、SSD、RAID、SAN、云硬盘等，因为它们有不同的特点测试指标：IOPS和MBPS(吞吐率)，下面会具体阐述测试工具：Linux下常用Fio、dd工具,Windows下常用IOMeter,测试参数:IO大小，寻址空间，队列深度，读写模式，随机/顺序模式测试方法：也就是测试步骤。
测试是为了对比，所以需要定性和定量。
在宣布自己的测试结果时，需要说明这次测试的工具、参数、方法，以便于比较。
存储系统模型为了更好的测试，我们需要先了解存储系统，块存储系统本质是一个排队模型，我们可以拿银行作为比喻。
还记得你去银行办事时的流程吗？去前台取单号等待排在你之前的人办完业务轮到你去某个柜台柜台职员帮你办完手续1柜台职员帮你办完手续2柜台职员帮你办完手续3办完业务，从柜台离开如何评估银行的效率呢：服务时间 = 手续1 + 手续2 + 手续3响应时间 = 服务时间 + 等待时间性能 = 单位时间内处理业务数量那银行如何提高效率呢:增加柜台数降低服务时间因此，排队系统或存储系统的优化方法是增加并行度降低服务时间硬盘测试硬盘原理我们应该如何测试SATA/SAS硬盘呢？首先需要了解磁盘的构造，并了解磁盘的工作方式：每个硬盘都有一个磁头(相当于银行的柜台)，硬盘的工作方式是：收到IO请求，得到地址和数据大小移动磁头(寻址)找到相应的磁道(寻址)读取数据传输数据则磁盘的随机IO服务时间:服务时间 = 寻道时间 + 旋转时间 + 传输时间对于转速的SATA硬盘来说，一般寻道时间是7 ms，旋转时间是3 ms, 64KB的传输时间是 0.8 ms， 则SATA硬盘每秒可以进行随机IO操作是 1000/(7 + 3 + 0.8) = 93，所以我们估算SATA硬盘64KB随机写的IOPS是93。
一般的硬盘厂商都会标明顺序读写的MBPS。
我们在列出IOPS时，需要说明IO大小，寻址空间，读写模式，顺序/随机，队列深度。
我们一般常用的IO大小是4KB，这是因为文件系统常用的块大小是4KB。
使用dd测试硬盘虽然硬盘的性能是可以估算出来的，但是怎么才能让应用获得这些性能呢？对于测试工具来说，就是如何得到IOPS和MBPS峰值。
我们先用dd测试一下SATA硬盘的MBPS(吞吐量)。
#dd if=/dev/zero of=/dev/sdd bs=4k count= oflag=direct记录了+0 的读入 记录了+0 的写出 字节(1.2 GB)已复制，17.958 秒，68.4 MB/秒#iostat -x sdd 5 : rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %utilsdd 0.00 0.00 0.00 .80 0.00 .40 8.00 0.79 0.05 0.05 78.82…为什么这块硬盘的MBPS只有68MB/s? 这是因为磁盘利用率是78%，没有到达95%以上，还有部分时间是空闲的。
当dd在前一个IO响应之后，在准备发起下一个IO时，SATA硬盘是空闲的。
那么如何才能提高利用率，让磁盘不空闲呢？只有一个办法，那就是增加硬盘的队列深度。
相对于CPU来说，硬盘属于慢速设备，所有操作系统会有给每个硬盘分配一个专门的队列用于缓冲IO请求。
队列深度什么是磁盘的队列深度？在某个时刻,有N个inflight的IO请求,包括在队列中的IO请求、磁盘正在处理的IO请求。
N就是队列深度。
加大硬盘队列深度就是让硬盘不断工作，减少硬盘的空闲时间。
加大队列深度 -> 提高利用率 -> 获得IOPS和MBPS峰值 -> 注意响应时间在可接受的范围内增加队列深度的办法有很多使用异步IO，同时发起多个IO请求，相当于队列中有多个IO请求多线程发起同步IO请求，相当于队列中有多个IO请求增大应用IO大小，到达底层之后，会变成多个IO请求，相当于队列中有多个IO请求 队列深度增加了。
队列深度增加了，IO在队列的等待时间也会增加，导致IO响应时间变大，这需要权衡。
让我们通过增加IO大小来增加dd的队列深度，看有没有效果：dd if=/dev/zero of=/dev/sdd bs=2M count=1000 oflag=direct记录了1000+0 的读入 记录了1000+0 的写出 字节(2.1 GB)已复制，10.6663 秒，197 MB/秒Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %utilsdd 0.00 0.00 0.00 380.60 0.00 .40 1024.00 2.39 6.28 2.56 97.42可以看到2MB的IO到达底层之后，会变成多个512KB的IO，平均队列长度为2.39，这个硬盘的利用率是97%，MBPS达到了197MB/s。
(为什么会变成512KB的IO，你可以去使用Google去查一下内核参数 max_sectors_kb的意义和使用方法 )也就是说增加队列深度，是可以测试出硬盘的峰值的。
使用fio测试硬盘现在，我们来测试下SATA硬盘的4KB随机写的IOPS。
因为我的环境是Linux，所以我使用FIO来测试。
$fio -ioengine=libaio -bs=4k -direct=1 -thread -rw=randwrite -size=1000G -filename=/dev/vdb \-name=EBS 4K randwrite test -iodepth=64 -runtime=60简单介绍fio的参数ioengine: 负载引擎，我们一般使用libaio，发起异步IO请求。
bs: IO大小direct: 直写，绕过操作系统Cache。
因为我们测试的是硬盘，而不是操作系统的Cache，所以设置为1。
rw: 读写模式，有顺序写write、顺序读read、随机写randwrite、随机读randread等。
size: 寻址空间，IO会落在 [0, size)这个区间的硬盘空间上。
这是一个可以影响IOPS的参数。
一般设置为硬盘的大小。
filename: 测试对象iodepth: 队列深度，只有使用libaio时才有意义。
这是一个可以影响IOPS的参数。
runtime: 测试时长下面我们做两次测试，分别 iodepth = 1和iodepth = 4的情况。
下面是iodepth = 1的测试结果。
上图中蓝色方框里面的是测出的IOPS 230, 绿色方框里面是每个IO请求的平均响应时间，大约是4.3ms。
黄色方框表示95%的IO请求的响应时间是小于等于 9.920 ms。
橙色方框表示该硬盘的利用率已经达到了98.58%。
下面是 iodepth = 4 的测试:我们发现这次测试的IOPS没有提高，反而IO平均响应时间变大了，是17ms。
为什么这里提高队列深度没有作用呢，原因当队列深度为1时，硬盘的利用率已经达到了98%，说明硬盘已经没有多少空闲时间可以压榨了。
而且响应时间为 4ms。
对于SATA硬盘，当增加队列深度时，并不会增加IOPS，只会增加响应时间。
这是因为硬盘只有一个磁头，并行度是1， 所以当IO请求队列变长时，每个IO请求的等待时间都会变长，导致响应时间也变长。
这是以前用IOMeter测试一块SATA硬盘的4K随机写性能，可以看到IOPS不会随着队列深度的增加而增加，反而是平均响应时间在倍增。
队列深度IOPS平均响应时间1332…………..1..7..寻址空间对IOPS的影响我们继续测试SATA硬盘，前面我们提到寻址空间参数也会对IOPS产生影响，下面我们就测试当size=1GB时的情况。
我们发现，当设置size=1GB时，IOPS会显著提高到568，IO平均响应时间会降到7ms(队列深度为4)。
这是因为当寻址空间为1GB时，磁头需要移动的距离变小了，每次IO请求的服务时间就降低了，这就是空间局部性原理。
假如我们测试的RAID卡或者是磁盘阵列(SAN)，它们可能会用Cache把这1GB的数据全部缓存，极大降低了IO请求的服务时间(内存的写操作比硬盘的写操作快很1000倍)。
所以设置寻址空间为1GB的意义不大，因为我们是要测试硬盘的全盘性能，而不是Cache的性能。
硬盘优化硬盘厂商提高硬盘性能的方法主要是降低服务时间(延迟)：提高转速(降低旋转时间和传输时间)增加Cache(降低写延迟，但不会提高IOPS)提高单磁道密度(变相提高传输时间)RAID测试RAID0/RAID5/RAID6的多块磁盘可以同时服务，其实就是提高并行度，这样极大提高了性能(相当于银行有多个柜台)。
以前测试过12块RAID0，100GB的寻址空间，4KB随机写，逐步提高队列深度，IOPS会提高，因为它有12块磁盘(12个磁头同时工作)，并行度是12。
队列深度IOPS平均响应时间……..7..0..0..42..13..RAID卡厂商优化的方法也是降低服务时间：使用大内存Cache使用IO处理器，降低XOR操作的延迟。
使用更大带宽的硬盘接口SAN测试对于低端磁盘阵列，使用单机IOmeter就可以测试出它的IOPS和MBPS的峰值，但是对于高端磁盘阵列，就需要多机并行测试才能得到IOPS和MBPS的峰值(IOmeter支持多机并行测试)。
下图是纪念照。
磁盘阵列厂商通过以下手段降低服务时间：更快的存储网络，比如FC和IB，延时更低。
读写Cache。
写数据到Cache之后就马上返回，不需要落盘。
而且磁盘阵列有更多的控制器和硬盘，大大提高了并行度。
现在的存储厂商会找SPC帮忙测试自己的磁盘阵列产品(或全闪存阵列)， 并给SPC支付费用，这就是赤裸裸的标准垄断。
国内也有做存储系统测试的，假如你要测试磁盘阵列，可以找NSTC (广告时间)。
SSD测试SSD的延时很低，并行度很高(多个nand块同时工作)，缺点是寿命和GC造成的响应时间不稳定。
推荐用IOMeter进行测试，使用大队列深度，并进行长时间测试，这样可以测试出SSD的真实性能。
下图是storagereview对一些SSD硬盘做的4KB随机写的长时间测试，可以看出有些SSD硬盘的最大响应时间很不稳定，会飙高到几百ms，这是不可接受的。
云硬盘测试我们通过两方面来提高云硬盘的性能的：降低延迟(使用SSD，使用万兆网络，优化代码，减少瓶颈)提高并行度(数据分片，同时使用整个集群的所有SSD)在Linux下测试云硬盘在Linux下，你可以使用FIO来测试操作系统：Ubuntu 14.04CPU： 2Memory: 2GB云硬盘大小： 1TB(SLA: 6000 IOPS, 170MB/s吞吐率)安装fio：#sudo apt-get install fio再次介绍一下FIO的测试参数：ioengine: 负载引擎，我们一般使用libaio，发起异步IO请求。
bs: IO大小direct: 直写，绕过操作系统Cache。
因为我们测试的是硬盘，而不是操作系统的Cache，所以设置为1。
rw: 读写模式，有顺序写write、顺序读read、随机写randwrite、随机读randread等。
size: 寻址空间，IO会落在 [0, size)这个区间的硬盘空间上。
这是一个可以影响IOPS的参数。
一般设置为硬盘的大小。
filename: 测试对象iodepth: 队列深度，只有使用libaio时才有意义。
这是一个可以影响IOPS的参数。
runtime: 测试时长4K随机写测试我们首先进行4K随机写测试，测试参数和测试结果如下所示：#fio -ioengine=libaio -bs=4k -direct=1 -thread -rw=randwrite -size=100G -filename=/dev/vdb \-name=EBS 4KB randwrite test -iodepth=32 -runtime=60蓝色方框表示IOPS是5900，在正常的误差范围内。
绿色方框表示IO请求的平均响应时间为5.42ms， 黄色方框表示95%的IO请求的响应时间是小于等于 6.24 ms的。
4K随机读测试我们再来进行4K随机读测试，测试参数和测试结果如下所示：#fio -ioengine=libaio -bs=4k -direct=1 -thread -rw=randread -size=100G -filename=/dev/vdb \-name=EBS 4KB randread test -iodepth=8 -runtime=KB顺序写测试最后我们来测试512KB顺序写，看看云硬盘的最大MBPS(吞吐率)是多少，测试参数和测试结果如下所示：#fio -ioengine=libaio -bs=512k -direct=1 -thread -rw=write -size=100G -filename=/dev/vdb \-name=EBS 512KB seqwrite test -iodepth=64 -runtime=60蓝色方框表示MBPS为KB/s，约为170MB/s。
使用dd测试吞吐率其实使用dd命令也可以测试出170MB/s的吞吐率，不过需要设置一下内核参数，详细介绍在 128MB/s VS 170MB/s 章节中。
在Windows下测试云硬盘在Windows下，我们一般使用IOMeter测试磁盘的性能，IOMeter不仅功能强大，而且很专业，是测试磁盘性能的首选工具。
IOMeter是图形化界面(浓浓的MFC框架的味道)，非常方便操作，下面我将使用IOMeter测试我们UOS上1TB的云硬盘。
操作系统：Window Server 2012 R2 64CPU： 4Memory: 8GB云硬盘大小： 1TB当你把云硬盘挂载到Windows主机之后，你还需要在windows操作系统里面设置硬盘为联机状态。
4K随机写测试打开IOMeter(你需要先下载)，你会看到IOMeter的主界面。
在右边，你回发现4个worker(数量和CPU个数相同)，因为我们现在只需要1个worker，所以你需要把其他3个worker移除掉。
现在让我们来测试硬盘的4K随机写，我们选择好硬盘(Red Hat VirtIO 0001)，设置寻址空间(Maximum Disk Size)为50GB(每个硬盘扇区大小是512B，所以一共是 50*1024*1024*1024/512 = )，设置队列深度(Outstanding I/Os)为64。
然后在测试集中选择”4KiB ALIGNED; 0% Read; 100% random(4KB对齐，100%随机写操作)” 测试然后设置测试时间，我们设置测试时长为60秒，测试之前的预热时间为10秒(IOMeter会发起负载，但是不统计这段时间的结果)。
在最后测试之前，你可以设置查看实时结果，设置实时结果的更新频率是5秒钟。
最后点击绿色旗子开始测试。
在测试过程中，我们可以看到实时的测试结果，当前的IOPS是6042，平均IO请求响应时间是10.56ms，这个测试还需要跑38秒，这个测试轮回只有这个测试。
我们可以看到IOMeter自动化程度很高，极大解放测试人员的劳动力，而且可以导出CSV格式的测试结果。
顺序读写测试我们再按照上面的步骤，进行了顺序读/写测试。
下面是测试结果：IO大小读写模式队列深度MBPS顺序写吞吐测试512KB顺序写.07 MB/s顺序读吞吐测试256KB顺序读.32 MB/s云硬盘的响应时间当前云硬盘写操作的主要延迟是网络传输多副本，写三份(数据强一致性)三份数据都落盘(数据持久化)之后，才返回IO处理逻辑我们当前主要是优化IO处理逻辑，并没有去优化2和3，这是因为我们是把用户数据的安全性放在第一位。
128MB/s VS 170MB/s回到最开始的问题 “为什么使用dd命令测试云硬盘只有128MB/s”， 这是因为目前云硬盘在处理超大IO请求时的延迟比SSD高(我们会不断进行优化)，现在我们有两种方法来获得更高的MBPS：设置max_sectors_kb为256 (系统默认为512)，降低延迟使用fio来测试，加大队列深度通过设置max_sectors_kb这个参数，使用dd也可以测出170MB/s的吞吐量root@ustack:~# cat /sys/block/vdb/queue/max_sectors_kb512root@ustack:~# echo 256 > /sys/block/vdb/queue/max_sectors_kbroot@ustack:~#root@ustack:~# dd if=/dev/zero of=/dev/vdb bs=32M count=40oflag=direct40+0 records in40+0 records ou bytes (1.3 GB) copied, 7. s, 179 MB/sroot@ustack:~#同时查看IO请求的延迟：root@ustack:~# iostat -x vdb 5 : rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm%utilvdb 0.000.00 0.00 688.00 0.00 ..00 54.5993.47 0.00 93.47 1.4096.56下面是使用fio工具的测试结果，也可以得到170MB/s的吞吐率。
不可测试的指标IOPS和MBPS是用户可以使用工具测试的指标，云硬盘还有一些用户不可测量的指标数据一致性数据持久性数据可用性这些指标我们只能通过根据系统架构和约束条件计算得到，然后转告给用户。
这些指标衡量着公有云厂商的良心，有机会会专门进行介绍。
总结上面介绍了一下测试工具和一些观点，希望对你有所帮助。
测试需要定性和定量了解存储模型可以帮助你更好的进行测试增加队列深度可以有效测试出IOPS和MBPS的峰值
怎么评判硬盘的好坏电脑硬盘如何看好坏
怎么评判硬盘的好坏(电脑硬盘如何看好坏)一、磁盘I/O的概念I/O的概念，从字义来理解就是输入输出。
操作系统从上层到底层，各个层次之间均存在I/O。
比如，cpu有I/O，内存有I/O,VMM有I/O,底层磁盘上也有I/O，这是广义上的I/O。
通常来讲，一个上层的I/O可能会产生针对磁盘的多个I/O，也就是说，上层的I/O是稀疏的，下层的I/O是密集的。
磁盘的I/O，顾名思义就是磁盘的输入输出。
输入指的是对磁盘写入数据，输出指的是从磁盘读出数据。
我们常见的磁盘类型有ATA、SATA、FC、SCSI、SAS，如图1所示。
这几种磁盘中，服务器常用的是SAS和FC磁盘，一些高端存储也使用SSD盘。
每一种磁盘的性能是不一样的。
图1.物理磁盘的架构以及常见磁盘类型二、性能评价指标SAN（StorageAreaNetwork,存储区域网络）和NAS存储（NetworkAttachedStorage，网络附加存储)一般都具备2个评价指标：IOPS和带宽（throughput），两个指标互相独立又相互关联。
体现存储系统性能的最主要指标是IOPS。
下面，将介绍一下这两个参数的含义。
IOPS(Input/OutputPerSecond)即每秒的输入输出量(或读写次数)，是衡量磁盘性能的主要指标之一。
IOPS是指单位时间内系统能处理的I/O请求数量，I/O请求通常为读或写数据操作请求。
随机读写频繁的应用，如OLTP(OnlineTransactionProcessing)，IOPS是关键衡量指标。
另一个重要指标是数据吞吐量(Throughput)，指单位时间内可以成功传输的数据数量。
对于大量顺序读写的应用，如VOD(VideoOnDemand)，则更关注吞吐量指标。
简而言之：磁盘的IOPS，也就是在一秒内，磁盘进行多少次I/O读写。
磁盘的吞吐量，也就是每秒磁盘I/O的流量，即磁盘写入加上读出的数据的大小。
IOPS与吞吐量的关系每秒I/O吞吐量＝IOPS*平均I/OSIZE。
从公式可以看出：I/OSIZE越大，IOPS越高，那么每秒I/O的吞吐量就越高。
因此，我们会认为IOPS和吞吐量的数值越高越好。
实际上，对于一个磁盘来讲，这两个参数均有其最大值，而且这两个参数也存在着一定的关系。
IOPS可细分为如下几个指标：ToatalIOPS，混合读写和顺序随机I/O负载情况下的磁盘IOPS，这个与实际I/O情况最为相符，大多数应用关注此指标。
RandomReadIOPS，100%随机读负载情况下的IOPS。
RandomWriteIOPS，100%随机写负载情况下的IOPS。
SequentialReadIOPS，100%顺序读负载情况下的IOPS。
SequentialWriteIOPS，100%顺序写负载情况下的IOPS。
下图为一个典型的NFS测试结果：IOPS的测试benchmark工具主要有Iometer,IoZone,FIO等，可以综合用于测试磁盘在不同情形下的IOPS。
对于应用系统，需要首先确定数据的负载特征，然后选择合理的IOPS指标进行测量和对比分析，据此选择合适的存储介质和软件系统。
IOPS计算公式对于磁盘来说一个完整的IO操作是这样进行的：当控制器对磁盘发出一个IO操作命令的时候，磁盘的驱动臂(ActuatorArm)带读写磁头(Head)离开着陆区(LandingZone，位于内圈没有数据的区域)，移动到要操作的初始数据块所在的磁道(Track)的正上方，这个过程被称为寻址(Seeking)，对应消耗的时间被称为寻址时间(SeekTime);但是找到对应磁道还不能马上读取数据，这时候磁头要等到磁盘盘片(Platter)旋转到初始数据块所在的扇区(Sector)落在读写磁头正上方的之后才能开始读取数据，在这个等待盘片旋转到可操作扇区的过程中消耗的时间称为旋转延时(RotationalDelay);接下来就随着盘片的旋转，磁头不断的读/写相应的数据块，直到完成这次IO所需要操作的全部数据，这个过程称为数据传送(DataTransfer)，对应的时间称为传送时间(TransferTime)。
完成这三个步骤之后一次IO操作也就完成了。
在我们看硬盘厂商的宣传单的时候我们经常能看到3个参数，分别是平均寻址时间、盘片旋转速度以及最大传送速度，这三个参数就可以提供给我们计算上述三个步骤的时间。
第一个寻址时间，考虑到被读写的数据可能在磁盘的任意一个磁道，既有可能在磁盘的最内圈(寻址时间最短)，也可能在磁盘的最外圈(寻址时间最长)，所以在计算中我们只考虑平均寻址时间，也就是磁盘参数中标明的那个平均寻址时间，这里就采用当前最多的10krmp硬盘的5ms。
第二个旋转延时，和寻址一样，当磁头定位到磁道之后有可能正好在要读写扇区之上，这时候是不需要额外额延时就可以立刻读写到数据，但是最坏的情况确实要磁盘旋转整整一圈之后磁头才能读取到数据，所以这里我们也考虑的是平均旋转延时，对于10krpm的磁盘就是(60s/10k)*(1/2)=2ms。
第三个传送时间，磁盘参数提供我们的最大的传输速度，当然要达到这种速度是很有难度的，但是这个速度却是磁盘纯读写磁盘的速度，因此只要给定了单次IO的大小，我们就知道磁盘需要花费多少时间在数据传送上，这个时间就是IOChunkSize/MaxTransferRate。
现在我们就可以得出这样的计算单次IO时间的公式。
IOTime=SeekTime+60sec/RotationalSpeed/2+IOChunkSize/TransferRate于是我们可以这样计算出IOPS。
IOPS=1/IOTime=1/(SeekTime+60sec/RotationalSpeed/2+IOChunkSize/TransferRate)对于给定不同的IO大小我们可以得出下面的一系列的数据4K(1/7.1ms=140IOPS)5ms+(60sec/RPM/2)+4K/40MB=5+2+0.1=7.18k(1/7.2ms=139IOPS)5ms+(60sec/RPM/2)+8K/40MB=5+2+0.2=7.216K(1/7.4ms=135IOPS)5ms+(60sec/RPM/2)+16K/40MB=5+2+0.4=7.432K(1/7.8ms=128IOPS)5ms+(60sec/RPM/2)+32K/40MB=5+2+0.8=7.864K(1/8.6ms=116IOPS)5ms+(60sec/RPM/2)+64K/40MB=5+2+1.6=8.6从上面的数据可以看出，当单次IO越小的时候，单次IO所耗费的时间也越少，相应的IOPS也就越大。
上面我们的数据都是在一个比较理想的假设下得出来的，这里的理想的情况就是磁盘要花费平均大小的寻址时间和平均的旋转延时，这个假设其实是比较符合我们实际情况中的随机读写，在随机读写中，每次IO操作的寻址时间和旋转延时都不能忽略不计，有了这两个时间的存在也就限制了IOPS的大小。
现在我们考虑一种相对极端的顺序读写操作，比如说在读取一个很大的存储连续分布在磁盘的的文件，因为文件的存储的分布是连续的，磁头在完成一个读IO操作之后，不需要从新的寻址，也不需要旋转延时，在这种情况下我们能到一个很大的IOPS值，如下。
4K(1/0.1ms=IOPS)0ms+0ms+4K/40MB=0.18k(1/0.2ms=5000IOPS)0ms+0ms+8K/40MB=0.216K(1/0.4ms=2500IOPS)0ms+0ms+16K/40MB=0.432K(1/0.8ms=1250IOPS)0ms+0ms+32K/40MB=0.864K(1/1.6ms=625IOPS)0ms+0ms+64K/40MB=1.6相比第一组数据来说差距是非常的大的，因此当我们要用IOPS来衡量一个IO系统的系能的时候我们一定要说清楚是在什么情况的IOPS，也就是要说明读写的方式以及单次IO的大小，当然在实际当中，特别是在OLTP的系统的，随机的小IO的读写是最有说服力的。
另外，对于同一个磁盘（或者LUN），随着每次I/O读写数据的大小不通，IOPS的数值也不是固定不变的。
例如，每次I/O写入或者读出的都是连续的大数据块，此时IOPS相对会低一些；在不频繁换道的情况下，每次写入或者读出的数据块小，相对来讲IOPS就会高一些。
也就是说，IOPS也取决与I/O块的大小，采用不同I/O块的大小测出的IOPS值是不同的。
对一个具体的IOPS,可以了解它当时测试的I/O块的尺寸。
并且IOPS都具有极限值，表1列出了各种磁盘的IOPS极限值。
表1.常见磁盘类型及其IOPS三、I/O读写的类型大体上讲，I/O的类型可以分为：读/写I/O、大/小块I/O、连续/随机I/O,顺序/并发I/O。
在这几种类型中，我们主要讨论一下：大/小块I/O、连续/随机I/O,顺序/并发I/O。
大/小块I/O这个数值指的是控制器指令中给出的连续读出扇区数目的多少。
如果数目较多，如64，128等，我们可以认为是大块I/O；反之，如果很小，比如4，8，我们就会认为是小块I/O，实际上，在大块和小块I/O之间，没有明确的界限。
连续/随机I/O连续I/O指的是本次I/O给出的初始扇区地址和上一次I/O的结束扇区地址是完全连续或者相隔不多的。
反之，如果相差很大，则算作一次随机I/O连续I/O比随机I/O效率高的原因是：在做连续I/O的时候，磁头几乎不用换道，或者换道的时间很短；而对于随机I/O，如果这个I/O很多的话，会导致磁头不停地换道，造成效率的极大降低。
顺序/并发I/O从概念上讲，并发I/O就是指向一块磁盘发出一条I/O指令后，不必等待它回应，接着向另外一块磁盘发I/O指令。
对于具有条带性的RAID（LUN），对其进行的I/O操作是并发的，例如：raid0+1(1+0),raid5等。
反之则为顺序I/O。
四、磁盘I/O性能调优确认磁盘I/O存在性能问题对于随机负载，当遇到余下情况时，我们那通常认为存在I/O性能问题：1.平均读时间大于15ms2.在具有写cache的条件下，平均写时间大于2.5ms对于顺序负载，当遇到余下情况时，我们那通常认为存在I/O性能问题：1.在一个磁盘上有两个连续的I/O流2.吞吐量不足（即远远小于磁盘I/O带宽）对于一块磁盘来讲，随着IOPS数量的增加，I/Oservice也会增加，并且会有一个饱和点，即IOPS达到某个点以后，IOPS再增加将会引起I/Oservicetime的显著增加。
图3.磁盘IOPS与IOservicetime关系图从经验上讲，我们在测试工作中，我们主要关注IOPS和吞吐量以及磁盘的busy%这三个数值。
如果IOPS和吞吐量均很低，磁盘的busy%也很低，我们会认为磁盘压力过小，造成吞吐量和IOPS过低；只有在IOPS和吞吐量均很低，磁盘的busy%很高（接近100%）的时候，我们才会从磁盘I/O方面分析I/O性能。
————————————————版权声明：本文为CSDN博主「风云龙儿」的原创文章，遵循CC4.0by-sa版权协议，转载请附上原文出处链接及本声明。
原文链接：
虚拟化服务器性能如何评估？
如果只有两个Guest OS,以规格来看，瓶颈应不会在CPU性能上，反而是硬盘I/O跟网络速度的性能比较有可能，而内存数量及使用规划也要注意。
另外如果是无法长期停机的机器，需要评估备份或后备规划，以及后备系统版权授权规定及费用。
关键瓶颈是磁盘I/O,并非CPU。
需要跟进的事情是﹕1. 在旧主机上面，先监测出跑报表所需要的IOPS有多少？并精算VM硬盘。
2. 如果文档复制会占用主机所有的IOPS,这种工作不适合跟其他VM共享磁盘。
所以，如果要拆开，主因并不是CPU不够用（跑报表跟文档复制，根本用不到多少CPU资源），而是磁盘的I/O资源会被文档复制全部占用，造成其他的VM排队等候。
在虚拟化软件的选择上，如果是VMware ESX（i），可以透过vSphere Client或vCenter新增Resource pool,来设定Guest OS的CPU资源。
可以测试一下：报表跑数据大量择取的时候，使用“Windows工作管理员/处理程序”查看CPU与内存以及I/O的状态。
虽然将它们放在同一台主机，但是文档服务给它一个完全独立的磁盘子系统，不跟其他VM共用，那这样就不会有以上的顾虑，还是可以放在一起。
例如，你可以买一台SAN给文档服务的VM专用，但另买一台SAN给其他的VM共用，最后，数据库的问题还是要回到IOPS上来。
我遇过80%以上想做虚拟化的新手，都不知道原本旧主机上数据库的瓶颈是在Disk I/O。
一般说来，跑ERP报表吃掉1,000~3,000 IOPS是很常见的状况，这代表RAID至少要5到15颗以上来组合，才足够应付这样的IOPS。
根据以往的经验，在看到这个数据之前，用户都一直认为瓶颈是CPU,所以要换新主机来提升CPU,但看过监测数据之后才知道，其实瓶颈都在IOPS。
补充一下，一般状况下，一颗SATA硬盘的IOPS只有70到80左右，一颗15K SAS硬盘的IOPS,大约200到240左右。
组成RAID多颗硬盘时，IOPS会跟着你的硬盘数量而增加，例如使用96颗硬盘组成RAID-5的一台Dell MD3200i,实测数据上，IOPS可以高达40,000。
