IOPS的疑惑

IOPS (Input/Output Operations Per Second, pronounced eye-ops) is a common performance measurement used tobenchmark computer storage devices like hard disk drives (HDD), solid state drives (SSD), and storage area networks (SAN).

http://en.wikipedia.org/wiki/IOPS

您的访问请求被拒绝 - ITeye技术社区

http://www.360doc.com/content/09/0916/10/5874_6034763.shtml

楼主举个应用例子先，比较好解释！

同求。

总感觉很难说清楚这个事情，不同层面上对IO定义不同，如果是针对磁盘阵列的，那就是写入阵列的应用IO多少，但是这里场景也有区别，比如是应用直接写入还是通过OS缓存写入，很难说清楚。

一般我在考虑IOPS的时候，都是结合以往业务的阵列使用情况来参考的，如果是新业务，就了解主要的行为特点（读写）及业务量（访问量的支撑指标，多少次），如果能够了解内存可以尝试估算一下系统级输出的IO（希望懂的大神指教一下），然后考虑硬盘转速、硬盘数量、Raid类型，看阵列能够提供后端IOPS（阵列内存->磁盘）是否能够包的住，如果量级较大，或者应用端加cache或者阵列上加大缓存。

IOPS, 即IO per second，也就是每秒进行IO读写的次数，是衡量存储性能的一个重要指标。

一个典型的I/O处理过程从应用到HBA，switch，存储前端端口，后端端口。在I/O处理过程中，要保证HBA卡的网络带宽、光纤交换机端口带宽、存储前端端口、后端端口的速度相匹配。

举个例子，一个典型的I/O数据处理过程：终端用户发起一次数据库读请求，这个请求到达DB Server之后，数据库优化器判断buffer pool中是否有它请求的数据，如果有，就直接从内存中读取，否则就要从硬盘中读；那么再判断如果采用的是裸设备，那么就去读逻辑卷，逻辑卷实在逻辑卷管理器（LVM）之上，LVM又在操作系统之上，操作系统和存储之间往往还有一个多路径软件可实现负载均衡和流量控制，多路径软件之下是存储供应商的设备驱动，主机服务器通过HBA卡和光纤交换机连接，光纤交换机和存储前端连接，存储前端再通过Cache连接后端的物理磁盘。

决定IOPS的主要因素在于阵列的算法、Cache命中率、以及磁盘的个数。阵列的算法会因阵列不同而有所区别，所以在进行存储I/O设计时，必须结合所使用的产品去了解阵列的算法规则与限制。Cache的命中率取决于数据的分布、Cache的大小、数据访问的规则，以及Cache的算法。

在日常存储设备选型中，硬盘的物理容量大小及接口类型对单个硬盘IOPS性能的影响可忽略，我们根据不同的硬盘转速及寻道时间计算IO性能来选择，以下常用的硬盘IOps理论值供参考

15000rpm 硬盘   1000/(2+3.5)≈180

10000rpm 硬盘 1000/(3+3.5) ≈150

7200rpm 硬盘   1000/(4.17+8) ≈  80

免费订阅论坛每月简报请点击   

首先要关注的就是主机层面应用程序的IOPS，比如数据库、邮件系统、NAS文件服务等，而决定这些应用IOPS的是实际的用户数量以及一些应用本身的高级功能（比如复制、镜像）所生成的额外IOPS，这就是最原始的IOPS需求。然后存储和网络端都是依据这原始IOPS进一步计算出其自身的IOPS需求的。

总之一句话，需求是应用程序和用户决定的，具体如何测算，是需要专门的人员和工具来度量的，楼上一些工程师也谈到了关于计算部分的内容。

个人感觉大部分时候都是估算的。主要是结合相同或类似的业务场景规模进行估计了。

有一个很好的公式，这个公式不使用阵列的IOPS值，而是根据业务workload值去推算阵列所需的IOPS，你可以参考一下：

(TOTAL Workload IOps × % READ)+ ((TOTAL Workload IOps × % WRITE) ×RAID Penalty)

举个栗子：

• Total IOPS need: 250 IOPS
• Read workload: 50%
• Write workload: 50%
• RAID level: 6 (IO penalty of 6)

250*50% + 250*50%*6= 875

你需要能提供875 IOPS的阵列，来支持250 IOPS， RAID 6，50%写的业务。

当然，如果加入Cache命中率等因素，公式会更加复杂。

你在自己的应用和服务器上跑个工具测试一下不就好了，高峰时候存储压力怎么样，每秒IO有多少，Response Time怎么样，Throughput是多少。如果业务翻倍，希望达到怎么样的效果？根据你的要求再寻找适合的存储。中间很多计算工作要做的。

我的意思是，总听到厂商说我们的存储达到多少多少IOPS，但是您怎么知道我们的系统要多少IOPS呢？我现在是对自己的系统要达到怎样的性能比较没把握。即从因推到果，而厂家总是直接给到一个果给我。我需要的是因。

厂商提供个200万IOPS的产品给你。在上面跑的应用只有5K，或者主要的衡量指标不是IOPS而是Throughput，显然没对症用药。所以我一开始问你，给个应用的例子先。

我理解你需要知道的是你自己业务的Workload，作为存储的工程师，最好是根据你提供给的workload来建议选择多大IOPS的存储，怎样测量客户业务的负载这方面不太精通，只能帮你到这里了

厂商不可能事先知道每一个客户的系统要多少IOPS。这个要么客户自己算，要么请厂商的售前工程师或professional service或solution team帮忙。如果你需要跑的应用是商业软件，比如SQL或Exchange，那这些软件的厂商也会有专门的文档阐述多少用户对应多少存储空间和IOPS的要求。

总之这块工作，要么花时间，要么花钱。

单看业务这块，确实很难弄到，就像买服务器时，我们说要多少台服务器的时候都用TPMC，但是有多少需求方能提供确切的TPMC呢（需要下很大的功夫）？在中国，几乎很少见，只是厂家会给你服务器TPMC的标准，但是这个标准都是按照一定应用模型来算的，具体到你平台基本上不会太适用。

一般的开发人员很难给出这些，几乎都是架构师在考虑这些事情，但是也只能给出根据业务逻辑估算的调用和访问，具体到阵列那，又隔着操作系统、内存、卷管理软件，可能还有一切优化的缓存和队列等手段。所以一般只能用一些性能计数器的工具来测试了，这一块弄好的都是高手啊！我觉的你还是把你的应用具体情况先描述一下吧，这里的高手也方便帮你评估。

到了阵列那评估怎么匹配，上边的EMC高手都发过言了，值得信赖！

同意你说的，就算问开发的人，他们也不知道一个应用要多少IOPS。对于不同的前端应用，负载，数据的IOPS完全不一样。除非一些完全没有定制化的系统，比如MS Exchange这种，倒是可以根据多少邮箱用户，每个用户每天发多少邮件算出来需要多少IOPS，然后规划存储。