星期四, 2020-08-06 03:40 — adminshiping1

centos 7 查看磁盘io ，找出占用io读写很高的进程

1，先用iostat查看磁盘io 是否读写负载很高

用# iostat -x 1 10

如果 iostat 没有，要 yum install sysstat安装这个包，第一眼看下图红色圈圈的那个如果%util接近100%,表明I/O请求太多,I/O系统已经满负荷，磁盘可能存在瓶颈,一般%util大于70%,I/O压力就比较大，读取速度有较多的wait，然后再看其他的参数，

rrqm/s:每秒进行merge的读操作数目。即delta(rmerge)/s
wrqm/s:每秒进行merge的写操作数目。即delta(wmerge)/s
r/s:每秒完成的读I/O设备次数。即delta(rio)/s
w/s:每秒完成的写I/0设备次数。即delta(wio)/s
rsec/s:每秒读扇区数。即delta(rsect)/s
wsec/s:每秒写扇区数。即delta(wsect)/s
rKB/s:每秒读K字节数。是rsec/s的一半，因为每扇区大小为512字节

wKB/s:每秒写K字节数。是wsec/s的一半
avgrq-sz:平均每次设备I/O操作的数据大小(扇区)。即delta(rsect+wsect)/delta(rio+wio)
avgqu-sz:平均I/O队列长度。即delta(aveq)/s/1000(因为aveq的单位为毫秒)
await:平均每次设备I/O操作的等待时间(毫秒)。即delta(ruse+wuse)/delta(rio+wio)
svctm:平均每次设备I/O操作的服务时间(毫秒)。即delta(use)/delta(rio+wio)
%util:一秒中有百分之多少的时间用于I/O操作,或者说一秒中有多少时间I/O队列是非空的

2，找出使用io高的进程的工具 iotop

yum install iotop -y

直接执行 # iotop 命令，然后看下图的显示，查看那个进程的读写，找出进程

来自 https://blog.csdn.net/saga_gallon/article/details/82891709

linux服务器硬盘IO读写负载高来源定位 pt-ioprofile

首先、用top命令查看　　

top - 16:15:05 up 6 days, 6:25, 2 users, load average: 1.45, 1.77, 2.14

　　Tasks: 147 total, 1 running, 146 sleeping, 0 stopped, 0 zombie

　　Cpu(s): 0.2% us, 0.2% sy, 0.0% ni, 86.9% id, 12.6% wa, 0.0% hi, 0.0% si

　　Mem: 4037872k total, 4003648k used, 34224k free, 5512k buffers

　　Swap: 7164948k total, 629192k used, 6535756k free, 3511184k cached

　　查看12.6% wa (指CPU等待磁盘写入完成的时间)

　　IO等待所占用的CPU时间的百分比,高过30%时IO压力高

　　其次、用iostat -x 1 10 (-x 选项将用于显示和io相关的扩展数据; 1表示间隔；10表示时间)

　　如果 iostat 没有，要 yum install sysstat　　

avg-cpu: %user %nice %sys %iowait %idle

　　0.00 0.00 0.25 33.46 66.29

　　Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s rkB/s wkB/s avgrq-sz avgqu-sz await svctm %util

　　sda 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

　　sdb 0.00 1122 17.00 9.00 192.00 9216.00 96.00 4608.00 123.79 137.23 1033.43 13.17 100.10

　　sdc 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00

　　查看%util 100.10 %idle 66.29

　　%util：在统计时间内所有处理IO时间，除以总共统计时间。例如，如果统计间隔1秒，该设备有0.8秒在处理IO，而0.2秒闲置，那么该设备的%util = 0.8/1 = 80%，所以该参数暗示了设备的繁忙程度。一般地，如果该参数是100%表示设备已经接近满负荷运行了（当然如果是多磁盘，即使%util是100%，因为磁盘的并发能力，所以磁盘使用未必就到了瓶颈）。

　　idle小于70% IO压力就较大了,一般读取速度有较多的wait.

　　同时可以结合vmstat 查看查看b参数(等待资源的进程数)　　

vmstat 1

IO负载高的来源定位

前言：
在一般运维工作中经常会遇到这么一个场景，服务器的IO负载很高（iostat中的util），但是无法快速的定位到IO负载的来源进程和来源文件导致无法进行相应的策略来解决问题。
这个现象在MySQL上更为常见，在5.6（performance_schema提供io instrument）之前，我们通常只能猜到是MySQL导致的高IO，但是没法定位具体是哪个文件带来的负载。
例如是ibdata的刷写？还是冷门ibd的随机读取？
本文就将介绍一个比较简单的定位IO高负载的流程。

工具准备：

iotop: http://guichaz.free.fr/iotop/

pt-ioprofile:http://www.percona.com/downloads/percona-toolkit/2.2.1/

Step1 : iostat 查看IO情况

iostat -x 1 查看IO情况，从下图可以看到dfa这个磁盘的IO负载较高，接下来我们就来定位具体的负载来源

Step2： iotop定位负载来源进程

iotop的本质是一个python脚本，从proc中获取thread的IO信息，进行汇总。

从下图可以看出大部分的IO来源都来自于mysqld进程。因此可以确定dfa的负载来源是数据库

# iotop 就可以查看到

然后在查看对应的进程是3527 然后执行 ll /proc/3527 可以查看到对应进程是什么进程,非常感谢您长期对我司的支持!

Step3 pt-ioprofile定位负载来源文件

pt-ioprofile的原理是对某个pid附加一个strace进程进行IO分析。

以下是摘自官网的一段警示：

However, it works by attaching strace to the process using ptrace(), which will make it run very slowly until strace detaches. In addition to freezing the server, there is also some risk of the process crashing or performing badly after strace detaches from it, or indeed of strace not detaching cleanly and leaving the process in a sleeping state. As a result, this should be considered an intrusive tool, and should not be used on production servers unless you are comfortable with that.

通过ps aux|grep mysqld 找到 mysqld进程对应的进程号，通过pt-ioprofile查看哪个文件的IO占用时间最多。

默认参数下该工具展示的是IO占用的时间。