[实践OK]linux下IO负载高因某颗CPU或者某几颗CPU进程导致的排查并定位解决办法之ps psr对应某颗CPU,iostat和iowait详细解说-查看磁盘IO瓶颈之定位到某个CPU上,或者从业务上发现服务器老旧出现的磁盘物理故障。

jackxiang 2019-11-11 09:52 | |
磁盘有问题:
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
评论列表
发表评论

昵称

网址

电邮

打开HTML 打开UBB 打开表情 隐藏 记住我 [登入] [注册]