IOPS 浅析

简介:
决定IOPS的因素主要取决与阵列的算法,cache命中率,以及磁盘个数。阵列的算法因为不同的阵列不同而不同,如我们最近遇到在hds usp上面,可能因为ldev(lun)存在队列或者资源限制,而单个ldev的iops就上不去,所以,在使用这个存储之前,有必要了解这个存储的一些算法规则与限制。  
cache的命中率取决于数据的分布,cache size的大小,数据访问的规则,以及cache的算法,如果完整的讨论下来,这里将变得很复杂,可以有一天好讨论了。这里只强调一个cache的命中率,如果一个阵列,读cache的命中率越高越好,一般表示它可以支持更多的IOPS,为什么这么说呢?这个就与我们下面要讨论的硬盘IOPS有关系了。硬盘的限制,每个物理硬盘能处理的IOPS是有限制的,如  
10 K rpm 15 K rpm ATA   
——— ——— ———   
100 150 50   
同样,如果一个阵列有120块15K rpm的光纤硬盘,那么,它能撑的最大IOPS为120*150=18000,这个为硬件限制的理论值,如果超过这个值,硬盘的响应可能会变的非常缓慢而不能正常提供业务。  
在raid5与raid10上,读iops没有差别,但是,相同的业务写iops,最终落在磁盘上的iops是有差别的,而我们评估的却正是磁盘的IOPS,如果达到了磁盘的限制,性能肯定是上不去了。那我们假定一个case,业务的iops是10000,读cache命中率是30%,读iops为60%,写iops为40%,磁盘个数为120,那么分别计算在raid5与raid10的情况下,每个磁盘的iops为多少。  
raid5:   
单块盘的iops = (10000*(1-0.3)*0.6 + 4 * (10000*0.4))/120 = (4200 + 16000)/120 = 168   
这里的10000*(1-0.3)*0.6表示是读的iops,比例是0.6,除掉cache命中,实际只有4200个iops 而4 * (10000*0.4) 表示写的iops,
因为每一个写,在raid5中,实际发生了4个io,所以写的iops为16000个  为了考虑raid5在写操作的时候,那2个读操作也可能发生命中,
所以更精确的计算为:  
单块盘的iops = (10000*(1-0.3)*0.6 + 2 * (10000*0.4)*(1-0.3) + 2 * (10000*0.4))/120= (4200 + 5600 + 8000)/120= 148   
计算出来单个盘的iops为148个,基本达到磁盘极限  
raid10
单块盘的iops = (10000*(1-0.3)*0.6 + 2 * (10000*0.4))/120 = (4200 + 8000)/120 = 102
可以看到,因为raid10对于一个写操作,只发生2次io,所以,同样的压力,同样的磁盘,每个盘的iops只有102个,还远远低于磁盘的极限iops。  
在一个实际的case中,一个恢复压力很大的standby(这里主要是写,而且是小io的写),采用了raid5的方案,发现性能很差,通过分析,每个磁盘的iops在高峰时期,快达到200了,导致响应速度巨慢无比。后来改造成 raid10,就避免了这个性能问题,每个磁盘的iops降到100左右。
相关文章
|
安全 项目管理
一文搞懂需求流程规范的制定方法和落地技巧
随着业务和产品的发展、团队的不断扩大,很多团队都不可避免的会遇到需求流程混乱的问题。虽然有的团队也编写了一些“需求流程规范”的文档,但最终却流于纸面,难以在团队真正落地。如何科学制定并有效落实需求管理规范呢?对此,云效产品经理陈逊进行了非常详细的直播分享,本文是他经验的文字总结。
103820 19
40个IPython的使用技巧整理
IPython 是一个强大的交互式 Python 解释器,它提供了许多增强的功能,使得 Python 编程更加高效和有趣。
|
域名解析 安全 Java
SpringBoot启动的时候初始化的线程池默认配置tomcat
SpringBoot启动的时候初始化的线程池默认配置tomcat
544 1
|
算法 NoSQL Java
6种限流实现,附代码![通俗易懂]
6种限流实现,附代码![通俗易懂]
1015 0
6种限流实现,附代码![通俗易懂]
|
数据采集 存储 消息中间件
《阿里大数据之路》读书笔记:总述
阿里数据体系主要分为数据采集、数据计算、数据服务和数据应用四大层次。
1335 0
|
网络协议 云计算
C/S模型与P2P模型
C/S 模型 TCP/IP协议在设计和实现上并没有客户端和服务器的概念,在通信过程中所有机器都是对等的。但由于资源(视频、新闻、软件等)都被数据提供者所垄断,所以几乎所有的网络应用程序都很自然地采用了C/S模型图所示的C/S (客户端/服务器)模型:所有客户端都通过访问服务器来获取所需的资源。
520 0
C/S模型与P2P模型
|
缓存 NoSQL 前端开发
前后端分离项目知识汇总(整合Redis)
前后端分离项目知识汇总(整合Redis)
353 0
|
存储 监控 大数据
阿里云InfluxDB®教你玩转A股数据
阿里云InfluxDB®目前已经商业化,专注于处理高写入和查询负载的时序数据,用于存储大规模的时序数据并进行实时分析,包括来自DevOps监控、车联网、智慧交通、金融和IOT传感器数据采集。金融中股票交易具有高频和时间属性,非常符合InfluxDB的应用场景。
12091 0
|
SQL 存储 数据库
时序数据库连载系列:当SQL遇到时序 TimescaleDB
1.概述 TimescaleDB是Timescale Inc.(成立于2015年)开发的一款号称兼容全SQL的 时序数据库 。它的本质是一个基于 PostgreSQL(以下简称 PG )的扩展( Extension ),主打的卖点如下: 全SQL支持 背靠PostgreSQL的高可靠性 时序数据的高写入性能 下文将对TimescaleDB这个产品进行解读。
7296 0

热门文章

最新文章