改善磁盘设备io性能linux,性能分析--磁盘IO

通过iostat命令分析CPU使用率和设备使用率,了解各指标含义,例如:%user,%system,%iowait等。案例展示了磁盘性能监控,如磁盘使用率100%导致的IO延迟问题。当CPU内核执行时间占比过高,可能存在应用程序导致的IO瓶颈。优化策略包括减少IO请求量、利用缓存等。
摘要由CSDN通过智能技术生成

iostat命令产生三类数据报表: cpu使用率、设备使用率、网络文件系统使用。下面先看一下前面两个数据指标的定义,以及如何帮助性能调优上发现问题点。

CPU使用率:

%user, 用户态的代码cpu执行时间占比

%nice, 带有nice优先级的用户态代码cpu使用时间占比

%system,内核态代码cpu使用占比

%iowait, 等待外部io的过程中,cpu空闲的时间占比

%steal,管理程序维护另一个虚拟处理器时,虚拟CPU的无意识等待时间百分比

%idle,cpu空闲时间占比

设备使用率:

tps, transfer per second,每秒io 请求个数

blk_read/s 每秒读的block的个数

blk_wrtn/s,每秒写的block的个数

blk_read,总共的读的block的个数

blk_wrtn,总共的写的block的个数

kb_read/s,每秒读的kb个数

kb_wrtn/s,每秒写的kb个数

mb_read/s,每秒读的mb个数

mb_wrtn/s每秒写的mb个数

mb_read,总共读的mb个数

mb_wrtn,总共写的mb个数

rrqm/s,read request mereded were queue , 每秒排队的合并的读请求

wrqm/s,每秒排队的合并的写请求

r/s,每秒发布的读请求

w/s,每秒发布的写请求

rsec/s,每秒读的扇区的个数

wsec/s,每秒写的扇区的个数

rKb/s,每秒读的kb

wKb/s,每秒写的kb

avgrq-sz,发布的请求的平均大小,以扇区为单位

avggqu-sz,发布的请求的平均队列大小

await,平均io的时间,包括在队列中的时间,和实际执行的时间

utils,设备利用率,如果接近100,说明设备负载饱和

案例1

1ebf1570d336

上面这个案例,查看是磁盘sda的性能情况。io写的指标w_await,平均耗时6ms,读平均耗时是5.33ms,磁盘使用率是1.04%,对于5200转速的硬盘来讲,这个性能数据看起来还可以。但是有一个地方有问题:cpu花在内核执行时间占比居然达到37.89%,超过用户占比23.45%。如果该机器上,还有别的程序在做io的事情,也许还可理解,但是如果只有被监测的目标程序一个,可能需要分析原因了。

有两个指标也可能提供了一些线索,w/s, wrqm/s,每秒写的请求个数和每秒进入写队列的请求个数。相对于wMB/s的0.14,每秒写0.14MB,但是io写的还是慢了。刚才提了,如果硬盘是5200转速的话,且有w_await佐证,单次io执行的速度并不慢,所以得需要看一下应用程序是如何进行io的。比如如果应用程序从用户态copy到内核态,然后再进行真正io,或者在内核态做了很多事情,都有可能导致这样的情况。

案例2:

1ebf1570d336

从这个图中,我们可以看到,磁盘使用率是饱和状态,达到了100%,写的平均耗时超过了871ms,队列中io请求个数超过1010,每秒写81M的数据。因为磁盘负荷饱和,io执行时间过长,导致CPU因为等待io而空闲,空闲时间占比超过了47.89%。为了改善性能,需要从应用程序层面想办法降低IO的数据量,比如数据缓存在内存里(如page cache)、后台异步方式落盘等等策略。

小结

对于io密集型的应用或者任务,需要密切关注io操作对性能的影响。掌握iostat,理解背后的指标意义,针对不同的类型的IO性能问题,进行分析,对症下药找到不同的解决方案。

  • 0
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值