【存储】如何计算IOPS ?

我们知道评估io性能的三个关键指标为:

 1 IOPS

   每秒钟处理的IO请求数量。IOPS是随机访问类型业务(OLTP类)很重要的一个参考指标。

 2 IO Response Time

   IO的响应时间。IO响应时间是从操作系统内核发出一个IO请求到接收到IO响应的时间。因此,IO Response time除了包括磁盘获取数据的时间,还包括了操作系统以及在存储系统内部IO等待的时间。

 3 Throughput

  吞吐量。这个指标衡量标识了最大的数据传输量。如上说明,这个值在顺序访问或者大数据量访问的情况下会比较重要。尤其在大数据量写的时候。

   如何计算IOPS ? 本文通过利用/proc/disksats 的内容来计算磁盘iops,如果是多个磁盘,需要多个变量来标记每个磁盘的累计值和前一秒的值,做减法操作。

首先介绍一下/proc/diskstats 的意义

root@rac1 markbench]# cat /proc/diskstats

   1    0 ram0 0 0 0 0 0 0 0 0 0 0 0

   1    1 ram1 0 0 0 0 0 0 0 0 0 0 0

   3    0 hda 215832 48798 8460369 1779489 10387352 10706454 278983110 129355207 12 30046343 131143587

   3    1 hda1 328 1805 2367 1482 24 11 61 1518 0 1499 3000

   3    2 hda2 214383 41704 8442154 1766493 10387210 10706256 278981160 129335402 12 30040228 131110596

   3    3 hda3 174 1250 1455 920 0 0 0 0 0 110 920

   3    4 hda4 4 0 8 9 0 0 0 0 0 9 9

   3    5 hda5 925 4006 13977 10447 118 187 1889 18287 0 7409 28734

  202   32 xvdc 38 76 912 14 0 0 0 0 0 14 14

  202   16 xvdb 40 76 928 17 0 0 0 0 0 17 17

  22    0 hdc 18 86 416 39 0 0 0 0 0 35 39

   9    0  md0 0 0 0 0 0 0 0 0 0 0 0

这个命令用于显示磁盘、分区和统计信息:hda为整个硬盘的统计信息,hda1为第一个分区的统计信息,hda2为第二个分区的统计信息。

ramdisk设备为通过软件将RAM当做硬盘来使用的一项技术。

[root@rac1 markbench]#  cat /sys/block/hda/hda2/stat

  214428    41704  8443522  1767344 10431899 10785067 282040104 130435808        9 30120018 132201965

/proc/diskstats文件比/sys/block/hda/hda2/stat文件多3列,从左至右分别对应主设备号,次设备号和设备名称。后续的11列的意义在这两个文件里是相同的,除了第9列,所有的域都是从启动时的累积值。 

第1 列 读完成次数,成功完成读的总次数。

(number of issued reads. This is the total number of reads completed successfully.)

第2 列 合并读完成次数, 第6 列合并写完成次数。为了效率可能会合并相邻的读和写。从而两次4K的读在它最终被处理到磁盘上之前可能会变成一次8K的读,才被计数(和排队),因此只有一次I/O操作。该值使你知道这样的操作有多频繁。

(number of reads merged)

第3 列 读扇区的次数,成功读过的扇区总次数。

(number of sectors read. This is the total number of sectors read successfully.)

第4 列 读花费的毫秒数,这是所有读操作所花费的毫秒数(用__make_request()到end_that_request_last()测量)。

(number of milliseconds spent reading. This is the total number of milliseconds spent by all reads (as measured from __make_request() to end_that_request_last()).)

第5 列 写完成次数,成功写完成的总次数。

(number of writes completed. This is the total number of writes completed successfully.)

第6 列 合并写完成次数  

(number of writes merged Reads and writes which are adjacent to each other may be merged for efficiency. Thus two 4K reads may become one 8K read before it is ultimately handed to the disk, and so it will be counted (and queued) as only one I/O. This field lets you know how often this was done.)

第7 列 写扇区次数,成功写扇区总次数。

(number of sectors written. This is the total number of sectors written successfully.)

第8 列 写操作花费的毫秒数,这是所有写操作所花费的毫秒数(用__make_request()到end_that_request_last()测量)。

(number of milliseconds spent writing This is the total number of milliseconds spent by all writes (as measured from __make_request() to end_that_request_last()).)

第9 列 正在处理的输入/输出请求数-I/O的当前进度,只有这个域应该是0。当请求被交给适当的request_queue_t时增加和请求完成时减小。

(number of I/Os currently in progress. The only field that should go to zero. Incremented as requests are given to appropriate request_queue_t and decremented as they finish.)

第10 列 输入/输出操作花费的毫秒数,花在I/O操作上的毫秒数,这个域会增长只要field 9不为0。

(number of milliseconds spent doing I/Os. This field is increased so long as field 9 is nonzero.)

第11 列 输入/输出操作花费的加权毫秒数  花在I/O操作上的毫秒数,在每次I/O开始,I/O结束,I/O合并时这个域都会增加。这可以给I/O完成时间和存储那些可以累积的提供一个便利的测量标准。

(number of milliseconds spent doing I/Os. This field is incremented at each I/O start, I/O completion, I/O merge, or read of these stats by the number of I/Os in progress (field 9) times the number of milliseconds spent doing I/O since the last update of this field. This can provide an easy measure of both I/O completion time and the backlog that may be accumulating.)

统计的iops 的脚本如下:

#!/bin/bash

uplrio=0

uplwio=0

updrio=0

updwio=0

while true ; do

        lrio=$(grep hda2 /proc/diskstats | awk '{print $4}')

        lwio=$(grep hda2 /proc/diskstats | awk '{print $8}')

        llrio=$(echo $lrio - $uplrio | bc)

        llwio=$(echo $lwio - $uplwio | bc)

        iops=$(echo "$llrio + $llwio " | bc)

        echo "iops:$iops Data_Read $llrio Data_Write $llwio "

        uplrio=$lrio

        uplwio=$lwio

        sleep 1

done

效果展示:

[root@rac1 markbench]# sh iops.sh 

iops:10348521 Data_Read 214045 Data_Write 10134476  --第一个因为是累计值-0的结果,所以比较大,可以忽略。

iops:322 Data_Read 0 Data_Write 322 

iops:596 Data_Read 0 Data_Write 596 

iops:589 Data_Read 0 Data_Write 589 

iops:615 Data_Read 0 Data_Write 615 

iops:599 Data_Read 0 Data_Write 599 

iops:455 Data_Read 0 Data_Write 455 

iops:533 Data_Read 0 Data_Write 533 

iops:516 Data_Read 0 Data_Write 516 

iops:214 Data_Read 0 Data_Write 214 

iops:544 Data_Read 0 Data_Write 544 

时间: 2025-01-24 01:11:13

【存储】如何计算IOPS ?的相关文章

cgroup测试存储设备IOPS分配

1 使用:创建树并且attach子系统 首先要创建文件系统的挂载点作为树的根 mkdir /cgroup/name mkdir /cgroup/cpu_and_mem Mount这个挂载点到一个或者多个子系统  mount -t cgroup -o subsystems name /cgroup/name  mount -t cgroup -o cpu,cpuset,memory cpu_and_mem /cgroup/cpu_and_mem 这个时候查看子系统  ~]# lssubsys -a

“云”上存储初显规模 如何架构是关键

   在安防系统中,存储设备只是给数据提供存储空间,数据存储的意义更多是为了给上层应用提供二次挖掘.目前的智能分析.大数据.图帧等技术都是基于数据存储做的数据挖掘.为了将二次挖掘应用的性能提升到最高,在优化分析算法的同时,在底层存储中将相应参数进行调整,适应高速的并发读写应用.例如现在的大数据就是基于云存储实现.将过车的图片和文本数据存储在云存储中,海量云存储系统在底层文件中参数进行修正,通过大数据服务器将信息进行读取.分析,实现百亿数据秒级检索. "云"上存储初显规模 如何架构是关键

iops performance loss by network and hypervisor

本文测试一下Linux NFS 网络文件系统, 以及在此之上跑虚拟机镜像的话, 会带来多少性能损失. 网络环境, 1000MB - 1000MB [root@39 ~]# ethtool em1 Settings for em1: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supported pause fra

存储极客谈“SPC-1负载分析与AFA寿命评估”

存储极客   这是一群存储偏执狂   为存储而生,跟存储死磕   各具独家秘笈   有观点,有碰撞,有干货   从2015年8月18起   做客存储极客栏目   与你分享存储里的那点事儿   企业存储界公认的SPC-1 Benchmark读写比例是多少.I/O大小如何.都是随机访问吗?以该测试成绩来估算闪存阵列的SSD寿命是否合理?有没有更好的办法?且听我们细细道来--   在<存储极客谈"如何绕开一堆复杂技术参数评估SSD寿命">一文中,一方面我们讨论了最直观的闪存写寿命

实力验证,浪潮整机柜软件定义存储性能有“数”可依

9月浪潮发布了整机柜软件定义存储新品AS13000-Rack,这款号称"业内首款"整机柜SDS一经上市,就受到了IT界上到权威人士.下到吃瓜群众的广泛关注.那么AS13000-Rack的运行表现到底如何?本着"真金不怕火炼"的实用原则,来看几组测试数据. 测试环境搭建 测试环境的配置是性能测试的基础,在介绍测试数据之前,先交代一下本次测试主角的软硬件配置. 4套整机柜SDS一字排开 为了验证新产品AS13000-Rack的运行表现,浪潮组织优秀的研发和测试团队对AS

何构建一个私有存储云

   企业构建内部云存储时必须考虑弹性,选择正确的平台,并允许工作流,堆栈部署和公共云集成. 每个云存储选项都有其优点和缺点.企业需要根据自己的具体需求,规模大小,以及资金预算来选择采用哪种云存储,重要的是权衡所有云和内部部署选项.可以下载一些综合指南,其中专家分析和评估当前可用的每个云存储选项,以便企业可以决定采用哪个云计算模式-公共云,私有云,或混合云. 企业如何去构建自己的私有存储云?首先,让我们回顾一下云计算的真正含义.云计算的标准定义包括以下特点:弹性增长和缩减消耗资源;交付即服务,以

如何架构企业内部的存储云

  存储即服务在近年来得到长足发展,越来越多的用户开始接受这种服务交付模式.今天的公有云服务商,如Amazon Web Services和Microsoft Azure,可以按需为内部或外部提供对象存储,以及数据块与文件存储,用于企业内部计算实例的分配.这给业务运营带来了极高的灵活性,比传统的存储部署方式更加方便且具有弹性,对数据中心颇有吸引力. 那么我们又当如何去构建私有化的存储云呢?首先让我们后退一步,回顾云计算的本质所在.云计算的标准定义中囊括了以下特点:弹性增长且减少资源消耗;作为一项服

降低成本 打造高性能定制中端存储

   目前,很多公司使用的存储服务器多为几年前采购的产品,随着公司业务的发展数据日益暴增,这些设备越来越无力承担,同时公司想通过这些数据挖掘更多的业务价值也变得越来越困难.如何解决这些问题?增加存储设备.采用虚拟化已经成为常用的手段,但是不同的设备如何统一管理?增加的数据存储成本谁来买单?数据的安全如何保障?已成为亟待解决的问题. 而IBM最新发布的虚拟化存储设备Storwize V5000看起来是个不错的选择. 成本优势 IBM Storwize V5000固有的精简调配技术能够通过提高磁盘利

私有存储云如何构建?

   构建内部的云存储必须考虑到弹性.选择正确的平台.支持工作流,以及批量部署和跟公有云的集成. 随着时间的推移,存储即服务的交付进展惊人.如今,公有云,如Amazon Web Services和Microsoft Azure,都提供了内部以及外部连接的按需分配的对象存储,以及块和文件存储,用于内部分配给计算实例.这种运维的灵活性在数据中心里很引人注意,比起传统的存储部署方式,它提供了更大的便捷性和敏捷性. 如何构建自己的私有存储云呢?我们首先退后一步,思考一下云计算到底意味着什么.云标准定义包