Linux高阶—磁盘性能分析iostat(二)

在分析存储性能之前,需要先了解存储性能定义的三个核心指标:IOPS、Throughput、await

  1. IOPS的含义是:存储每秒钟可以处理的IO的个数;
  2. Throughput吞吐量(带宽)的含义是:存储每秒能处理的数据的总量,单位是MB/S;
  3. Await响应时间:单位时间内I/O延时。

有些人就会说了:你说的定义是否正确?不会胡说八道吧!上图说话:

第一张图:

  1. 业界存储技术性能天花板企业宣传说IOPS能达到 2100000(存储在所有磁盘写满的情况下每一秒的IO处理能力),我相信对于一个世界500强企业能说这样话,肯定做个相关业务压测才能输出结果,数据来源应该可靠。
  2. 从业界存储技术性能天花板企业指标监控图可以看出,决定存储性能的三个指标就是IOPS、Throughput、await 

Linux高阶—磁盘性能分析iostat(二)_第1张图片

第二张图:

  1. 开源的FIO也是三个性能指标,按单个磁盘、8KB块、读测试,测试结果信息看方框的数据:

Linux高阶—磁盘性能分析iostat(二)_第2张图片

  1. IOPS:存储每秒钟可以处理的IO的个数iops=35639
  2. Throughput:bw=285116KB/S=278MB/S
  3. Await:lat(usec代表微秒) ,平均响应时间avg=223.73微秒=0.2毫秒

看到上面的数据,可能又有人发起挑战了:你的存储带宽每秒钟只能写300MB上下,你这性能太差了吧!

博主可能心里又会想了:这个屌毛,真会找事!心里已经默默骂了一千遍。

正面就这么说:原因是小文件太多了,每秒都快4万了,40000*8KB=320000KB/1024≈300MB,文件数瓶颈导致带宽上不去,反之加大block块大小,文件数下降带宽就能上去了。

总结了以下几种应用场景推荐:

  1. 小文件随机读写的应用要求存储具有足够的I/O能力,所以要求较高的IOPS,在乎的是处理个数;
  2. 大文件持续传输型的应用需要的是存储具有充分的带宽(Throughput吞吐量)性能,在乎处理时长;
  3. 读写需要快速响应,比如说游戏操控,那就关注磁盘await响应时间。

FIO测试案例:

使用FIO进行读写操作为高危操作,请务必提前查询和确认好用于FIO测试的卷挂载详情,并在后续测试过程中,严格使用查询到的测试卷设备名,避免出现对系统盘或者其他业务数据卷进行误操作。

rw=randwread             测试随机读的I/O

rw=randwrite             测试随机写的I/O

rw=read               测试顺序读的I/O

rw=write               测试顺序写的I/O

rw=rw                测试顺序混合写和读的I/O

rw=randrw               测试随机混合写和读的I/O,默认写占30%,读占70%

rwmixwrite=30             在混合读写的模式下,写占30%

1、小块8K随机读:fio -filename=/dev/sdb -direct=1 -rw=randread -bs=8K  -numjobs=8 -runtime=180 -group_reporting -name=8KB_randread_sdb -output=/tmp/8K_randread_sdb.log  -randrepeat=0 -norandommap&

2、小块8K随机写:fio -filename=/dev/sdb -direct=1 -rw=randwrite -bs=8K  -numjobs=8 -runtime=180 -group_reporting -name=8KB_randwrite_sdb -output=/tmp/8K _randwrite_sdb.log  -randrepeat=0 -norandommap&

3、小块8K随机混合读写:fio -filename=/dev/sdb -direct=1 -rw=randrw -bs=8K  -numjobs=8 -runtime=180 -group_reporting -name=8KB_randrw_sdb -output=/tmp/8K_randrw_sdb.log  -randrepeat=0 -norandommap&

4、大块1M顺序读:fio -filename=/dev/sdb -direct=1 -rw=read -bs=1m  -numjobs=8 -runtime=180 -group_reporting -name=1M_read_sdb -output=/tmp/1M_read_sdb.log  -randrepeat=0 -norandommap&

5、大块1M顺序写:fio -filename=/dev/sdb -direct=1 -rw=write -bs=1m  -numjobs=8 -runtime=180 -group_reporting -name=1M_write_sdb -output=/tmp/1M_write_sdb.log  -randrepeat=0 -norandommap&​

总结以上论证就是说:存储的性能是由三个核心指标:iops、throughput、await来定义存储是不是有性能瓶颈,通过FIO工具可以很直观的展现。

听完博主的论文觉得前言太多了,赶紧进入主题吧!

疑问:iostat工具统计的存储使用率指标 %util能代表存储性能瓶颈吗?

先做一下性能数据收集,然后再仔细分析:

  1. linux查看磁盘block块大小:/sbin/tune2fs -l /dev/mapper/root_vg-varlv | grep "Block size"或者“stat filename |grep "IO Block"”。
  2. oracle数据库查看block块大小:show parameter db_block_size
  3. 通过命令实时查看磁盘负荷情况:iostat –xkd 1,输入如下信息:

38caefc348d6450bbe65080f0a1c6b85.png

还是重点关注3个性能核心指标:iopsthroughputawait与多个任务指标。

iops r/s每秒读处理的IO个数;

iops w/s每秒写处理的IO个数;

throughput:rKB/s每秒从设备读取的千字节数;

throughput:wKB/s每秒写入设备的千字节数;

awaitr_await每一个读IO请求的处理的响应时间,单位是毫秒;

awaitw_await每一个写IO请求的处理的响应时间,单位是毫秒;

aqu-sz表示磁盘I/O队列数;

svctm表示平均每次设备I/O操作的服务时间(以毫秒为单位);

%util 单位时间内处理IO的时间比。例如:单位时间为间隔1秒,该设备有0.8秒在处理IO,而0.2秒闲置,那么该设备的%util = 0.8/1 = 80%。

iostat和atop统计的IO对比:

数据处理次数iops:iostat.r/s ->atop.read 
数据处理次数iops:iostat.w/s -> atop.write 
吞吐量(带宽)throughput:iostat.rkB/s -> atop.MBr/s 
吞吐量(带宽)throughput:iostat.wkB/s -> atop.MBw/s 
响应时间 await:iostat.await -> atop.avio

单位时间内处理IO的时间比:iostat.%util-> atop.busy
I/O 等待队列长度: iostat.avgqu-sz -> atop.avq 
平均 I/O 数据尺寸,每次请求的大小:iostat.avgrq-sz -> atop.KiB/r & KiB/w 

如何通过以上指标数据判断磁盘有没有瓶颈呢?

  1. 查看await值,响应时间是不是长期响应慢,如果是那肯定有问题;
  2. 查看svctm的值与await很接近,说明IO任务提交之后,IO立即响应了,表示几乎没有I/O等待,磁盘性能很好,反之则有问题;
  3. 查看aqu-sz队列值,越小越好,反之差值越大,队列越大,说明有问题;
  4. 查看iops与业务block块大小对比FIO压测数据,看有没有到瓶颈;
  5. 将throughput数据相加(或者执行sar -n DEV 1 统计网口流量)与光纤能支持的网络带宽对比,看有没有到网络传输瓶颈。

总结:可以通过以上5点判断存储是否有瓶颈,查看%util值能说明设备的繁忙程度,磁盘繁忙不代表性能有问题,只能说明磁盘一直在IO读写。为什么磁盘读写这么繁忙,需要从业务属性去排查。以数据库场景为例,业务查询时:确定一下表数据是不是很大;SQL查询逻辑是否合理;是否有索引;字符集是否一致;内存页太小等都会占用资源,需要业务侧去排查。

上一篇:Linux高阶—自动化安装操作系统PXE+Kickstart(一)

下一篇:Linux高阶—CPU性能分析vmstat(三)

你可能感兴趣的:(Linux,高阶知识,linux)