[实践OK]linux下IO负载高因某颗CPU或者某几颗CPU进程导致的排查并定位解决办法之ps psr对应某颗CPU，iostat和iowait详细解说-查看磁盘IO瓶颈之定位到某个CPU上，或者从业务上发现服务器老旧出现的磁盘物理故障。
磁盘有问题：
sudo badblocks -s -v -o sdbbadblocks.log /dev/sda #出现一堆的坏块编号
dmesg |less -i #jbd2，当有硬盘坏道时，通常在dmesg输出的信息中会有 Buffer I/O Error，所以经常检查dmesg的输出可以及时发现是否存在硬盘问题。
NFO: task jbd2/dm-3-8:526 blocked for more than 120 seconds.
Not tainted 2.6.32-431.el6.x86_64 #1
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
jbd2/dm-3-8 D 0000000000000002 0 526 2 0x00000000
查看第2个CPU上的程序定位到jbd2：
|grep -v '\[' 去掉系统服务进程
ps -eo 'pid,psr,cmd' |sort -nk 2|awk '{if($2==2)print }'|grep -v '\['
ps -eo 'pid,psr,cmd' |sort -nk 2|awk '{if($2==2)print }'|grep '\['
ls -l /dev/dm-3
brw-rw---- 1 root disk 253, 3 Nov 11 14:59 /dev/dm-3
ps -LF -p 526 #看它的主进程
UID PID PPID LWP C NLWP SZ RSS PSR STIME TTY TIME CMD
root 526 2 526 0 1 0 0 2 Nov11 ? 00:00:00 [jbd2/dm-3-8]
lsof -nPp 526
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
jbd2/dm-3 526 root cwd DIR 253,3 4096 2 /
jbd2/dm-3 526 root rtd DIR 253,3 4096 2 /
jbd2/dm-3 526 root txt unknown /proc/526/exe
dmraid -r #man dmraid
/dev/sda: ddf1, ".ddf1_disks", GROUP, ok, 285155328 sectors, data@ 0
/dev/sdb: ddf1, ".ddf1_disks", GROUP, ok, 285155328 sectors, data@ 0
lsblk -f #RAID1：数据安全性高，即同样的数据在另一块盘上备份一份，硬盘的容量也就减少一半。
NAME FSTYPE LABEL UUID MOUNTPOINT
sdb ddf_raid_member LSI \x10
└─ddf1_4c5349202020202010000055000000004711471100001450 (dm-0)
├─ddf1_4c5349202020202010000055000000004711471100001450p1 (dm-1) ext4 bef5de45-511b-41c2-b487-6cf98faf978a /boot
├─ddf1_4c5349202020202010000055000000004711471100001450p2 (dm-2) swap 861a3dbd-ca4b-4c97-b2b8-51504ee45949 [SWAP]
└─ddf1_4c5349202020202010000055000000004711471100001450p3 (dm-3) ext4 410be0c5-9b55-490e-b924-606d46182ea2 /
sda ddf_raid_member LSI \x10
└─ddf1_4c5349202020202010000055000000004711471100001450 (dm-0)
├─ddf1_4c5349202020202010000055000000004711471100001450p1 (dm-1) ext4 bef5de45-511b-41c2-b487-6cf98faf978a /boot
├─ddf1_4c5349202020202010000055000000004711471100001450p2 (dm-2) swap 861a3dbd-ca4b-4c97-b2b8-51504ee45949 [SWAP]
└─ddf1_4c5349202020202010000055000000004711471100001450p3 (dm-3) ext4 410be0c5-9b55-490e-b924-606d46182ea2 /
dmraid -s
*** Group superset .ddf1_disks
--> Active Subset
name : ddf1_4c5349202020202010000055000000004711471100001450
size : 285155328
stride : 128
type : mirror
status : ok
subsets: 0
devs : 2
spares : 0
步骤一） top命令显示后 按1
Cpu2 : 0.0%us, 0.0%sy, 0.0%ni, 0.0%id,100.0%wa, 0.0%hi, 0.0%si, 0.0%st
wa -- iowait AmountoftimetheCPUhasbeenwaitingfor I/O to complete.
步骤二）iostat -x 2 5 #定位各个磁盘读写哪个高一些,iostat 会每2秒更新一次，一共打印5次信息， -x 的选项是打印出扩展信息，实际使用得需要扩展信息-x得到svctm一项，反应了磁盘的负载情况，如果该项大于15ms，并且util%接近100%，那就说明，磁盘现在是整个系统性能的瓶颈了。
svctm: 平均每次设备I/O操作的服务时间 (毫秒)。即 delta(use)/delta(rio+wio)
%util: 一秒中有百分之多少的时间用于 I/O 操作，或者说一秒中有多少时间 I/O 队列是非空的。即 delta(use)/s/1000 (因为use的单位为毫秒)
如果 %util 接近 100%，说明产生的I/O请求太多，I/O系统已经满负荷，该磁盘可能存在瓶颈。
avgqu-sz: 平均I/O队列长度。即 delta(aveq)/s/1000 (因为aveq的单位为毫秒)。
浅显易懂的解释：
平均服务时间(svctm)类似于收银员的收款速度
平均等待时间(await)类似于平均每人的等待时间
I/O 操作率 (%util)类似于收款台前有人排队的时间比例。
实践发现dm-0 / dm-3 卡住了，产生的I/O请求太多，I/O系统已经满负荷，该磁盘可能存在瓶颈，也可能是坏了，
第一个iostat 报告会打印出系统最后一次启动后的统计信息，这也就是说，在多数情况下，第一个打印出来的信息应该被忽略，剩下的报告，都是基于上一次间隔的时间。举例子来说，这个命令会打印5次，第二次的报告是从第一次报告出来一个后的统计信息，第三次是基于第二次 ，依次类推：
iostat -x 2 5 # %util 出现100，设备是挂载的dm-0
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
dm-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 2.00 0.00 0.00 100.00
#dm-0的%utilized 是100.00%，这个很好的说明了有进程正在写入到dm-0磁盘中。
dm是device mapper（设备映射）的意思：
dm-0是个块设备，就是个分区，他被挂载在不同的目录，但是不同目录里的文件却不一样。
svctm 一般要小于 await (因为同时等待的请求的等待时间被重复计算了)，如果 svctm 比较接近 await，说明 I/O 几乎没有等待时间；如果 await 远大于 svctm，说明 I/O 队列太长，应用得到的响应时间变慢，如果响应时间超过了用户可以容许的范围，这时可以考虑更换更快的磁盘......。
步骤三）查找引起高I/O wait 对应的进程 ，iotop #查找I/O wait 对应的进程
步骤四）查找哪个文件引起的I/Owait：
lsof 命令可以展示一个进程打开的所有文件，或者打开一个文件的所有进程。从这个列表中，我们可以找到具体是什么文件被写入，根据文件的大小和/proc中io文件的具体数据
我们可以使用-p <pid>的方式来减少输出，pid是具体的进程
lsof -p 1028
步骤四）更深入的确认这些文件被频繁的读写，我们可以通过如下命令来查看
[root@localhost ~]# df /tmp
文件系统 1K-块 已用 可用 已用% 挂载点
/dev/mapper/cl-root 17811456 3981928 13829528 23% /
从上面的命令结果来看，我们可以确定/tmp 是我们环境的逻辑磁盘的根目录
复制代码
复制代码
[root@localhost ~]# pvdisplay
--- Physical volume ---
PV Name /dev/sda2
VG Name cl
PV Size 19.00 GiB / not usable 3.00 MiB
Allocatable yes (but full)
PE Size 4.00 MiB
Total PE 4863
Free PE 0
Allocated PE 4863
PV UUID 4QfaOy-DNSO-niK1-ayn2-K6AY-WZMy-9Nd2It
复制代码
复制代码
过pvdisplay我们能看到/dev/sda2其实就是我们用来创建逻辑磁盘的具体磁盘。通过以上的信息我们可以放心的说lsof的结果就是我们要查找的文件
cat /proc/18987/io
rchar: 58891582418
wchar: 58891579778
syscr: 46556085
syscw: 46556077
read_bytes: 212992
write_bytes: 59580235776
cancelled_write_bytes: 0
同时可以结合vmstat 查看查看b参数(等待资源的进程数),b有一个等待：
vmstat
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 1 0 11119256 238876 205460 0 0 0 0 2 3 0 0 99 1 0
来自：https://www.cnblogs.com/happy-king/p/9234122.html
sudo badblocks -s -v -o sdbbadblocks.log /dev/sda #出现一堆的坏块编号
dmesg |less -i #jbd2，当有硬盘坏道时，通常在dmesg输出的信息中会有 Buffer I/O Error，所以经常检查dmesg的输出可以及时发现是否存在硬盘问题。
NFO: task jbd2/dm-3-8:526 blocked for more than 120 seconds.
Not tainted 2.6.32-431.el6.x86_64 #1
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
jbd2/dm-3-8 D 0000000000000002 0 526 2 0x00000000
查看第2个CPU上的程序定位到jbd2：
|grep -v '\[' 去掉系统服务进程
ps -eo 'pid,psr,cmd' |sort -nk 2|awk '{if($2==2)print }'|grep -v '\['
ps -eo 'pid,psr,cmd' |sort -nk 2|awk '{if($2==2)print }'|grep '\['
ls -l /dev/dm-3
brw-rw---- 1 root disk 253, 3 Nov 11 14:59 /dev/dm-3
ps -LF -p 526 #看它的主进程
UID PID PPID LWP C NLWP SZ RSS PSR STIME TTY TIME CMD
root 526 2 526 0 1 0 0 2 Nov11 ? 00:00:00 [jbd2/dm-3-8]
lsof -nPp 526
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
jbd2/dm-3 526 root cwd DIR 253,3 4096 2 /
jbd2/dm-3 526 root rtd DIR 253,3 4096 2 /
jbd2/dm-3 526 root txt unknown /proc/526/exe
dmraid -r #man dmraid
/dev/sda: ddf1, ".ddf1_disks", GROUP, ok, 285155328 sectors, data@ 0
/dev/sdb: ddf1, ".ddf1_disks", GROUP, ok, 285155328 sectors, data@ 0
lsblk -f #RAID1：数据安全性高，即同样的数据在另一块盘上备份一份，硬盘的容量也就减少一半。
NAME FSTYPE LABEL UUID MOUNTPOINT
sdb ddf_raid_member LSI \x10
└─ddf1_4c5349202020202010000055000000004711471100001450 (dm-0)
├─ddf1_4c5349202020202010000055000000004711471100001450p1 (dm-1) ext4 bef5de45-511b-41c2-b487-6cf98faf978a /boot
├─ddf1_4c5349202020202010000055000000004711471100001450p2 (dm-2) swap 861a3dbd-ca4b-4c97-b2b8-51504ee45949 [SWAP]
└─ddf1_4c5349202020202010000055000000004711471100001450p3 (dm-3) ext4 410be0c5-9b55-490e-b924-606d46182ea2 /
sda ddf_raid_member LSI \x10
└─ddf1_4c5349202020202010000055000000004711471100001450 (dm-0)
├─ddf1_4c5349202020202010000055000000004711471100001450p1 (dm-1) ext4 bef5de45-511b-41c2-b487-6cf98faf978a /boot
├─ddf1_4c5349202020202010000055000000004711471100001450p2 (dm-2) swap 861a3dbd-ca4b-4c97-b2b8-51504ee45949 [SWAP]
└─ddf1_4c5349202020202010000055000000004711471100001450p3 (dm-3) ext4 410be0c5-9b55-490e-b924-606d46182ea2 /
dmraid -s
*** Group superset .ddf1_disks
--> Active Subset
name : ddf1_4c5349202020202010000055000000004711471100001450
size : 285155328
stride : 128
type : mirror
status : ok
subsets: 0
devs : 2
spares : 0
步骤一） top命令显示后 按1
Cpu2 : 0.0%us, 0.0%sy, 0.0%ni, 0.0%id,100.0%wa, 0.0%hi, 0.0%si, 0.0%st
wa -- iowait AmountoftimetheCPUhasbeenwaitingfor I/O to complete.
步骤二）iostat -x 2 5 #定位各个磁盘读写哪个高一些,iostat 会每2秒更新一次，一共打印5次信息， -x 的选项是打印出扩展信息，实际使用得需要扩展信息-x得到svctm一项，反应了磁盘的负载情况，如果该项大于15ms，并且util%接近100%，那就说明，磁盘现在是整个系统性能的瓶颈了。
svctm: 平均每次设备I/O操作的服务时间 (毫秒)。即 delta(use)/delta(rio+wio)
%util: 一秒中有百分之多少的时间用于 I/O 操作，或者说一秒中有多少时间 I/O 队列是非空的。即 delta(use)/s/1000 (因为use的单位为毫秒)
如果 %util 接近 100%，说明产生的I/O请求太多，I/O系统已经满负荷，该磁盘可能存在瓶颈。
avgqu-sz: 平均I/O队列长度。即 delta(aveq)/s/1000 (因为aveq的单位为毫秒)。
浅显易懂的解释：
平均服务时间(svctm)类似于收银员的收款速度
平均等待时间(await)类似于平均每人的等待时间
I/O 操作率 (%util)类似于收款台前有人排队的时间比例。
实践发现dm-0 / dm-3 卡住了，产生的I/O请求太多，I/O系统已经满负荷，该磁盘可能存在瓶颈，也可能是坏了，
第一个iostat 报告会打印出系统最后一次启动后的统计信息，这也就是说，在多数情况下，第一个打印出来的信息应该被忽略，剩下的报告，都是基于上一次间隔的时间。举例子来说，这个命令会打印5次，第二次的报告是从第一次报告出来一个后的统计信息，第三次是基于第二次 ，依次类推：
iostat -x 2 5 # %util 出现100，设备是挂载的dm-0
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util
dm-0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 2.00 0.00 0.00 100.00
#dm-0的%utilized 是100.00%，这个很好的说明了有进程正在写入到dm-0磁盘中。
dm是device mapper（设备映射）的意思：
dm-0是个块设备，就是个分区，他被挂载在不同的目录，但是不同目录里的文件却不一样。
svctm 一般要小于 await (因为同时等待的请求的等待时间被重复计算了)，如果 svctm 比较接近 await，说明 I/O 几乎没有等待时间；如果 await 远大于 svctm，说明 I/O 队列太长，应用得到的响应时间变慢，如果响应时间超过了用户可以容许的范围，这时可以考虑更换更快的磁盘......。
步骤三）查找引起高I/O wait 对应的进程 ，iotop #查找I/O wait 对应的进程
步骤四）查找哪个文件引起的I/Owait：
lsof 命令可以展示一个进程打开的所有文件，或者打开一个文件的所有进程。从这个列表中，我们可以找到具体是什么文件被写入，根据文件的大小和/proc中io文件的具体数据
我们可以使用-p <pid>的方式来减少输出，pid是具体的进程
lsof -p 1028
步骤四）更深入的确认这些文件被频繁的读写，我们可以通过如下命令来查看
[root@localhost ~]# df /tmp
文件系统 1K-块 已用 可用 已用% 挂载点
/dev/mapper/cl-root 17811456 3981928 13829528 23% /
从上面的命令结果来看，我们可以确定/tmp 是我们环境的逻辑磁盘的根目录
复制代码
复制代码
[root@localhost ~]# pvdisplay
--- Physical volume ---
PV Name /dev/sda2
VG Name cl
PV Size 19.00 GiB / not usable 3.00 MiB
Allocatable yes (but full)
PE Size 4.00 MiB
Total PE 4863
Free PE 0
Allocated PE 4863
PV UUID 4QfaOy-DNSO-niK1-ayn2-K6AY-WZMy-9Nd2It
复制代码
复制代码
过pvdisplay我们能看到/dev/sda2其实就是我们用来创建逻辑磁盘的具体磁盘。通过以上的信息我们可以放心的说lsof的结果就是我们要查找的文件
cat /proc/18987/io
rchar: 58891582418
wchar: 58891579778
syscr: 46556085
syscw: 46556077
read_bytes: 212992
write_bytes: 59580235776
cancelled_write_bytes: 0
同时可以结合vmstat 查看查看b参数(等待资源的进程数),b有一个等待：
vmstat
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 1 0 11119256 238876 205460 0 0 0 0 2 3 0 0 99 1 0
来自：https://www.cnblogs.com/happy-king/p/9234122.html
作者：jackxiang@向东博客 专注WEB应用 构架之美 --- 构架之美，在于尽态极妍 | 应用之美，在于药到病除
地址：https://jackxiang.com/post/10343/
版权所有。转载时必须以链接形式注明作者和原始出处及本声明！
最后编辑： jackxiang 编辑于2021-5-26 07:37
为什么执行自己的程序要在前面加./
[实践OK]/etc/fstab 不用重启生效的方法修改过/etc/fs评论列表
