查询mysql中的数据 响应缓慢_一次数据库响应缓慢的问题排查

今天客户说有一个job跑的特别慢。想看看到底是不是数据库这边有什么问题了。

使用top来查看，io wait将近30%，已经算是负载比较重的了。

和客户确认从什么时候发现速度开始变慢的，他们说大概是从中午以后。

使用sar来看一下，确实是从iowait从:1:00开始有了大量的io

10:40:01

AM       CPU

%user     %nice   %system

%iowait    %steal     %idle

10:50:02

AM       all

7.59      0.00

1.38      3.82

0.00     87.21

11:00:01

AM       all

7.59      0.00

1.48      4.21

0.00     86.72

11:10:01

AM       all

7.46      0.00

1.69      4.52

0.00     86.33

11:20:01

AM       all

7.59      0.00

1.66      4.61

0.00     86.14

11:30:01

AM       all

7.47      0.00

1.53      4.37

0.00     86.62

11:40:01

AM       all

6.40      0.00

0.73      2.17

0.00     90.71

11:50:01

AM       all

6.04      0.00

0.55      1.51

0.00     91.89

12:00:02

PM       all

5.92      0.00

0.54      1.64

0.00     91.91

12:10:01

PM       all

5.95      0.00

0.82      2.01

0.00     91.23

12:20:02

PM       all

6.28      0.00

0.82      1.92

0.00     90.98

12:30:01

PM       all

6.82      0.00

0.90      2.06

0.00     90.22

12:40:01

PM       all

7.94      0.00

1.47      3.52

0.00     87.06

12:50:01

PM       all

8.01      0.00

1.55      3.78

0.00     86.65

01:00:01

PM       all

8.45      0.00

1.27     26.44

0.00     63.83

01:10:01

PM       all

7.28      0.00

1.05     47.89

0.00     43.78

01:20:01

PM       all

7.25      0.00

0.96     47.00

0.00     44.78

01:30:02

PM       all

7.62      0.00

1.04     44.31

0.00     47.03

01:40:01

PM       all

7.80      0.00

1.14     40.77

0.00     50.29

01:50:02 PM

all      7.99

0.00      1.15

44.40      0.00     46.46

02:00:01

PM       all

7.90      0.00

1.15     38.89

0.00     52.07

02:10:01

PM       all

7.16      0.00

1.15     43.83

0.00     47.85

02:20:01

PM       all

7.27      0.00

1.06     38.18

0.00     53.49

02:30:01

PM       all

7.29      0.00

1.04     35.64

0.00     56.03

02:40:01

PM       all

7.13      0.00

1.13     43.12

0.00     48.62

02:50:01

PM       all

8.45      0.01

1.36     43.24

0.00     46.95

03:00:02

PM       all

7.89      0.00

1.20     36.92

0.00     53.98

03:10:01

PM       all

6.73      0.00

1.09     42.51

0.00     49.68

03:20:02

PM       all

6.82      0.00

0.96     42.68

0.00     49.54

03:30:01

PM       all

6.64      0.00

0.95     44.15

0.00     48.26

03:40:02

PM       all

7.19      0.00

1.09     37.35

0.00     54.36

03:50:01

PM       all

6.70      0.00

1.06     39.24

0.00     53.00

04:00:02

PM       all

6.70      0.00

1.04     43.66

0.00     48.60

04:10:01

PM       all

6.98      0.00

1.08     40.17

0.00     51.77

04:20:02

PM       all

6.96      0.00

1.02     31.54

0.00     60.48

Average:

all      6.41

0.00      0.75

9.96      0.00     82.87

对于cpu的使用率高的问题，据我所知，这几天在做性能测试，cpu的消耗是可以接受的。

但是io的问题得有一个让人信服的结论，于是我使用dd来做了一个简单地测试，发现确实有很大的差距，

> time dd if=/dev/zero bs=1M count=204 of=direct_200M

414+0 records in

414+0 records out

434110464 bytes (434 MB) copied, 103.742 seconds, 4.2 MB/s在另外一个环境中做了对比测试，> time dd if=/dev/zero bs=1M count=204 of=direct_200M

204+0 records in

204+0 records out

213909504 bytes (214 MB) copied, 1.44182 seconds, 148 MB/s

real    0m1.445s

user    0m0.001s

sys     0m0.039s

所以问题可以和unix team来协调了。昨天晚上的时候客户反馈确实是san存储出了问题,当时正在做san存储的切换，所以导致访问速度受到影响。

早上就验证了一下。

> time dd if=/dev/zero bs=1M count=204 of=direct_200M

204+0 records in

204+0 records out

213909504 bytes (214 MB) copied, 0.448161 seconds, 477 MB/s

real    0m0.459s

user    0m0.001s

sys     0m0.061s