标题：[实践OK]linux下IO负载高因某颗CPU或者某几颗CPU进程导致的排查并定位解决办法之ps psr对应某颗CPU，iostat和iowait详细解说-查看磁盘IO瓶颈之定位到某个CPU上，或者从业务上发现服务器老旧出现的磁盘物理故障。 出处：向东博客 专注WEB应用 构架之美 --- 构架之美，在于尽态极妍 | 应用之美，在于药到病除 时间：Mon, 11 Nov 2019 09:52:09 +0000 作者：jackxiang 地址：http://jackxiang.com/post/10343/ 内容： 磁盘有问题： 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 '\[' 1086836 2 php-fpm: pool www 1086839 2 php-fpm: pool www 1086847 2 php-fpm: pool www 1086854 2 php-fpm: pool www 1086863 2 php-fpm: pool www 1774627 2 /usr/libexec/ibus-engine-simple 1995 2 /usr/bin/dbus-daemon --system --address=systemd: --nofork --nopidfile --systemd-activation --syslog-only 2041 2 /bin/bash /usr/sbin/ksmtuned 222374 2 svlogd -tt /var/log/gitlab/sshd 222842 2 runsv redis-exporter 222919 2 nginx: worker process 223003 2 svlogd -tt /var/log/gitlab/alertmanager 2623 2 /usr/bin/containerd 2991 2 nginx: worker process 4605 2 /usr/libexec/qemu-kvm -name guest=tmp-study-10-10-0-110,debug-threads=on 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 iostat -d # Device: tps Blk_read/s Blk_wrtn/s Blk_read Blk_wrtn sdb 0.15 0.14 1.49 246296 2567784 sda 0.15 0.47 1.49 813594 2567784 dm-0 0.21 0.33 1.49 567298 2567784 dm-1 0.00 0.01 0.00 25040 136 dm-2 0.00 0.00 0.00 4744 0 dm-3 0.21 0.31 1.49 536578 2567648 #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是具体的进程 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 Generated by Jackxiang's Bo-blog 2.1.1 Release