1000字范文,内容丰富有趣,学习的好帮手!
1000字范文 > Mysql disk write 高_优化系列|实例解析MySQL性能瓶颈排查定位 导读 排查过程

Mysql disk write 高_优化系列|实例解析MySQL性能瓶颈排查定位 导读 排查过程

时间:2020-04-01 17:44:53

相关推荐

Mysql disk write 高_优化系列|实例解析MySQL性能瓶颈排查定位
导读
排查过程

导读

从一个现场说起,全程解析如何定位性能瓶颈。

排查过程

收到线上某业务后端的MySQL实例负载比较高的告警信息,于是登入服务器检查确认。

1. 首先我们进行OS层面的检查确认

登入服务器后,我们的目的是首先要确认当前到底是哪些进程引起的负载高,以及这些进程卡在什么地方,瓶颈是什么。

通常来说,服务器上最容易成为瓶颈的是磁盘I/O子系统,因为它的读写速度通常是最慢的。即便是现在的PCIe SSD,其随机I/O读写速度也是不如内存来得快。当然了,引起磁盘I/O慢得原因也有多种,需要确认哪种引起的。

第一步,我们一般先看整体负载如何,负载高的话,肯定所有的进程跑起来都慢。

可以执行指令 w 或者 sar -q 1 来查看负载数据,例如(横版查看):

[yejr@:~ ]# w

11:52:58 up 702 days, 56 min, 1 user, load average: 7.20, 6.70, 6.47

USER TTY FROM LOGIN@ IDLE JCPU PCPU WHAT

root pts/0 1.xx.xx.xx 11:51 0.00s 0.03s 0.00s w

或者 sar -q 的观察结果(横版查看):

[yejr@:~ ]# sar -q 1

Linux 2.6.32-431.el6.x86_64 () 01/13/ _x86_64_ (24 CPU)

02:51:18 PM runq-sz plist-sz ldavg-1 ldavg-5 ldavg-15 blocked

02:51:19 PM 4 2305 6.41 6.98 7.12 3

02:51:20 PM 2 2301 6.41 6.98 7.12 4

02:51:21 PM 0 2300 6.41 6.98 7.12 5

02:51:22 PM 6 2301 6.41 6.98 7.12 8

02:51:23 PM 2 2290 6.41 6.98 7.12 8

load average大意表示当前CPU中有多少任务在排队等待,等待越多说明负载越高,跑数据库的服务器上,一般load值超过5的话,已经算是比较高的了。

引起load高的原因也可能有多种:

某些进程/服务消耗更多CPU资源(服务响应更多请求或存在某些应用瓶颈);

发生比较严重的swap(可用物理内存不足);

发生比较严重的中断(因为SSD或网络的原因发生中断);

磁盘I/O比较慢(会导致CPU一直等待磁盘I/O请求);

这时我们可以执行下面的命令来判断到底瓶颈在哪个子系统(横版查看):

[yejr@:~ ]# top

top - 11:53:04 up 702 days, 56 min, 1 user, load average: 7.18, 6.70, 6.47

Tasks: 576 total, 1 running, 575 sleeping, 0 stopped, 0 zombie

Cpu(s): 7.7%us, 3.4%sy, 0.0%ni, 77.6%id, 11.0%wa, 0.0%hi, 0.3%si, 0.0%st

Mem: 49374024k total, 3844k used, 17355180k free, 115416k buffers

Swap: 16777208k total, 117612k used, 16659596k free, 5689020k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME COMMAND

14165 mysql 20 0 8822m 3.1g 4672 S 162.3 6.6 89839:59 mysqld

40610 mysql 20 0 25.6g 14g 8336 S 121.7 31.5 282809:08 mysqld

49023 mysql 20 0 16.9g 5.1g 4772 S 4.6 10.8 34940:09 mysqld

很明显是前面两个mysqld进程导致整体负载较高。

而且,从 Cpu(s) 这行的统计结果也能看的出来,%us 和 %wa 的值较高,表示当前比较大的瓶颈可能是在用户进程消耗的CPU以及磁盘I/O等待上。

我们先分析下磁盘I/O的情况。

执行 sar -d 确认磁盘I/O是否真的较大(横版查看):

[yejr@:~ ]# sar -d 1

Linux 2.6.32-431.el6.x86_64 () 01/13/ _x86_64_ (24 CPU)

11:54:32 AM dev8-0 5338.00 162784.00 1394.00 30.76 5.24 0.98 0.19 100.00

11:54:33 AM dev8-0 5134.00 148032.00 32365.00 35.14 6.93 1.34 0.19 100.10

11:54:34 AM dev8-0 5233.00 161376.00 996.00 31.03 9.77 1.88 0.19 100.00

11:54:35 AM dev8-0 4566.00 139232.00 1166.00 30.75 5.37 1.18 0.22 100.00

11:54:36 AM dev8-0 4665.00 145920.00 630.00 31.41 5.94 1.27 0.21 100.00

11:54:37 AM dev8-0 4994.00 156544.00 546.00 31.46 7.07 1.42 0.20 100.00

再利用 iotop 确认到底哪些进程消耗的磁盘I/O资源最多(横版查看):

[yejr@:~ ]# iotop

Total DISK READ: 60.38 M/s | Total DISK WRITE: 640.34 K/s

TID PRIO USER DISK READ DISK WRITE SWAPIN IO

Tag标签:

本内容不代表本网观点和政治立场,如有侵犯你的权益请联系我们处理。
网友评论
网友评论仅供其表达个人看法,并不表明网站立场。