一次数据库响应缓慢的问题排查(r2第9天)

时间:2022-05-04
本文章向大家介绍一次数据库响应缓慢的问题排查(r2第9天),主要内容包括其使用实例、应用技巧、基本知识点总结和需要注意事项,具有一定的参考价值,需要的朋友可以参考一下。

今天客户说有一个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来做了一个简单地测试,发现确实有很大的差距,所以问题可以和unix team来协调了。

> 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