使用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
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/25462274/viewspace-1963538/ ，如需转载，请注明出处，否则将追究法律责任。
