https://blog.csdn.net/vic_qxz/article/details/80584687

一、环境

1.服务器环境
Centos 7.3 16核64G AliCloud

2.问题
服务器的Iowait time达到60%

二、排查流程

1.通过top命令发现服务器的Iowait time非常高,严重影响服务器性能。

  1. [root@zhangwan22222222 ~]# top
  2. top 15:07:40 up 2 days, 23:35, 10 users, load average: 5.02, 5.72, 6.97
  3. Tasks: 560 total, 1 running, 558 sleeping, 0 stopped, 1 zombie
  4. %Cpu0 : 8.7 us, 1.7 sy, 0.0 ni, 20.6 id, 69.0 wa, 0.0 hi, 0.0 si, 0.0 st
  5. %Cpu1 : 19.5 us, 1.7 sy, 0.0 ni, 78.5 id, 0.3 wa, 0.0 hi, 0.0 si, 0.0 st
  6. %Cpu2 : 38.3 us, 2.7 sy, 0.0 ni, 57.0 id, 2.0 wa, 0.0 hi, 0.0 si, 0.0 st
  7. %Cpu3 : 5.3 us, 0.3 sy, 0.0 ni, 94.4 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
  8. %Cpu4 : 40.1 us, 3.3 sy, 0.0 ni, 52.5 id, 4.0 wa, 0.0 hi, 0.0 si, 0.0 st
  9. %Cpu5 : 1.3 us, 0.3 sy, 0.0 ni, 98.3 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
  10. %Cpu6 : 25.2 us, 3.0 sy, 0.0 ni, 71.2 id, 0.7 wa, 0.0 hi, 0.0 si, 0.0 st
  11. %Cpu7 : 2.0 us, 0.3 sy, 0.0 ni, 97.7 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
  12. %Cpu8 : 36.0 us, 3.0 sy, 0.0 ni, 60.7 id, 0.3 wa, 0.0 hi, 0.0 si, 0.0 st
  13. %Cpu9 : 11.3 us, 1.0 sy, 0.0 ni, 87.7 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
  14. %Cpu10 : 26.2 us, 2.7 sy, 0.0 ni, 70.8 id, 0.3 wa, 0.0 hi, 0.0 si, 0.0 st
  15. %Cpu11 : 8.7 us, 3.0 sy, 0.0 ni, 88.0 id, 0.0 wa, 0.0 hi, 0.3 si, 0.0 st
  16. %Cpu12 : 25.3 us, 2.3 sy, 0.0 ni, 72.3 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
  17. %Cpu13 : 1.7 us, 7.3 sy, 0.0 ni, 91.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
  18. %Cpu14 : 28.7 us, 5.3 sy, 0.0 ni, 64.0 id, 2.0 wa, 0.0 hi, 0.0 si, 0.0 st
  19. %Cpu15 : 2.3 us, 1.0 sy, 0.0 ni, 96.7 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
  20. KiB Mem : 65808484 total, 467080 free, 14657588 used, 50683816 buff/cache
  21. KiB Swap: 0 total, 0 free, 0 used. 50511032 avail Mem

2.定位问题磁盘

  1. [root@zhangwan22222222 xc]# iostat -x 2 5
  2. Linux 3.10.0-514.26.2.el7.x86_64 (zhangwan22222222) 01/07/2018 _x86_64_ (16 CPU)
  3. avg-cpu: %user %nice %system %iowait %steal %idle
  4. 33.53 0.00 5.00 25.59 0.00 35.89
  5. Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
  6. vda 25.03 1022.15 4257.57 734.19 196186.95 9116.98 82.26 15.91 3.18 3.16 3.33 0.16 79.69
  7. dm-0 0.00 0.00 0.00 0.00 0.00 0.00 21.14 0.00 0.00 0.00 0.00 0.00 0.00
  8. avg-cpu: %user %nice %system %iowait %steal %idle
  9. 9.67 0.00 0.63 1.75 0.00 87.96
  10. Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
  11. vda 4.00 92.50 680.00 113.50 36380.00 856.00 93.85 1.61 2.03 2.27 0.60 0.40 31.60
  12. dm-0 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
  13. avg-cpu: %user %nice %system %iowait %steal %idle
  14. 6.60 0.00 0.69 0.34 0.00 92.37
  15. Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
  16. vda 0.00 76.00 94.00 96.00 4070.00 690.00 50.11 0.24 1.25 1.74 0.78 0.42 8.05
  17. dm-0 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
  18. avg-cpu: %user %nice %system %iowait %steal %idle
  19. 37.27 0.00 4.78 1.97 0.00 55.97
  20. Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
  21. vda 0.00 679.50 185.50 986.50 9398.00 6804.00 27.65 1.10 0.94 2.17 0.71 0.34 40.05
  22. dm-0 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
  23. avg-cpu: %user %nice %system %iowait %steal %idle
  24. 56.36 0.00 6.56 2.16 0.00 34.92
  25. Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
  26. vda 0.00 1031.00 105.50 1325.00 5252.00 10276.00 21.71 1.08 0.75 2.00 0.65 0.30 42.60
  27. dm-0 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

上边的例子中,iostat 会每2秒更新一次,一共打印5次信息, -x 的选项是打印出扩展信息

第一个iostat 报告会打印出系统最后一次启动后的统计信息,这也就是说,在多数情况下,第一个打印出来的信息应该被忽略,剩下的报告,都是基于上一次间隔的时间。

在上面的例子中,vda的%util 是42.60%,说明了有进程正在写入到vda磁盘中。

3.查看哪个进程占用的I/O过高

使用iotop,ps,lsof
iotop

  1. Total DISK READ : 51.40 M/s | Total DISK WRITE : 25.98 M/s
  2. Actual DISK READ: 51.44 M/s | Actual DISK WRITE: 28.12 M/s
  3. TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND
  4. 29746 be/4 mysql 50.51 M/s 122.75 K/s 0.00 % 40.81 % mysqld –basedir=/us~ysql.sock –port=3306
  5. 375 be/3 root 0.00 B/s 30.69 K/s 0.00 % 20.85 % [jbd2/vda1-8]

我没有记录当时的数据,这是解决后的。当时统计出来大量占用io读写的是mysql和[jbd2/vda1-8]

4.使用ps命令定位问题io进程

我们每5秒获取一次,一共获取10次。

  1. [root@zhangwan22222222 xc]# for x in `seq 1 1 10`; do ps -eo state,pid,cmd | grep “^D”; echo “—-“; sleep 5; done
  2. D 375 [jbd2/vda1-8]
  3. —-
  4. D 375 [jbd2/vda1-8]
  5. —-
  6. D 375 [jbd2/vda1-8]
  7. D 2747 sendmail: w0784B99002747 localhost [127.0.0.1]: DATA
  8. —-
  9. D 375 [jbd2/vda1-8]
  10. —-
  11. D 375 [jbd2/vda1-8]
  12. —-
  13. D 375 [jbd2/vda1-8]
  14. D 2878 php /web/phalcontest_2/task/run main main 24
  15. —-
  16. D 375 [jbd2/vda1-8]
  17. —-
  18. —-
  19. D 375 [jbd2/vda1-8]
  20. —-
  21. —-

D的状态一般是I/O出现了问题,说明进程在等待I/O,可以是磁盘I/O,网络I/O或者其他,详细:
https://blog.xupeng.me/2009/07/09/linux-uninterruptible-sleep-state/

到这里我们已经可以发现是pid为375的jbd2/vda1-8进程的问题。

5.lsof -p可以定位到进程写入的文件

  1. [root@zhangwan22222222 xc]# lsof -p 375
  2. COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
  3. jbd2/vda1 375 root cwd DIR 253,1 4096 2 /
  4. jbd2/vda1 375 root rtd DIR 253,1 4096 2 /
  5. jbd2/vda1 375 root txt unknown /proc/375/exe

这里定位到文件我不知道如何利用,但是我们已经知道了问题进程。

三、解决

1.

使用iotop发现这个进程 jdb2/sdb1-8 使用率高达40%到90%。

2.修改mysql参数

(1)第一步

修改sync_binlog=1为sync_binlog=10
因为sync_binlog=1导致事务写入太频繁,改为10后Iowait time明显下降。

可能还有个参数innodb_flush_log_at_trx_commit也会影响io性能,我设置的这个值是2,所以就没有修改

以下摘自网络:

sync_binlog”:这个参数是对于MySQL系统来说是至关重要的,他不仅影响到Binlog对MySQL所带来的性能损耗,而且还影响到MySQL中数据的完整性。对于“sync_binlog”参数的各种设置的说明如下:

sync_binlog=0,当事务提交之后,MySQL不做fsync之类的磁盘同步指令刷新binlog_cache中的信息到磁盘,而让Filesystem自行决定什么时候来做同步,或者cache满了之后才同步到磁盘。

sync_binlog=n,当每进行n次事务提交之后,MySQL将进行一次fsync之类的磁盘同步指令来将binlog_cache中的数据强制写入磁盘。

在MySQL中系统默认的设置是sync_binlog=0,也就是不做任何强制性的磁盘刷新指令,这时候的性能是最好的,但是风险也是最大的。因为一旦系统Crash,在binlog_cache中的所有binlog信息都会被丢失。而当设置为“1”的时候,是最安全但是性能损耗最大的设置。因为当设置为1的时候,即使系统Crash,也最多丢失binlog_cache中未完成的一个事务,对实际数据没有任何实质性影响。

从以往经验和相关测试来看,对于高并发事务的系统来说,“sync_binlog”设置为0和设置为1的系统写入性能差距可能高达5倍甚至更多。

这里的解决方法转自:
http://www.cnblogs.com/z-books/p/7324949.html

(2)第二步
这一步要根据自己服务器的情况修改,多核cpu可以通过这两个参数更有效的利用cpu性能

  1. innodb_write_io_threads = 32
  2. #脏页写的线程数,加大该参数可以提升写入性能.mysql5.5以上才有。
  3. innodb_read_io_threads = 16
  4. #读取

 

 

 

转载至https://blog.csdn.net/qq_32642039/article/details/78995617

发表评论

邮箱地址不会被公开。 必填项已用*标注