我有一个运行CentOS 6的服务器,它在mdadm RAID1中配置了两个关键的M500 SSD。这个服务器也是用Xen虚拟化的。
最近,我开始看到iowait百分比在我们的生产VM的top -c统计数据中缓慢上升。我决定在dom0上调查和运行iostat,这样我就可以检查物理磁盘上的活动(例如/dev/sda和/dev/sdb)。这是我使用的命令:iostat -d -x 3 3
下面是我收到的输出的一个例子(向右滚动%util数字):
Device: rrqm/s wrqm/s r/s w/s rsec/s wsec/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 0.33 0.00 38.67 0.00 337.33 8.72 0.09 2.22 0.00 2.22 1.90 7.33
sdb 0.00 0.33 0.00 38.67 0.00 338.00 8.74 1.08 27.27 0.00 27.27 23.96 92.63
md2 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
md1 0.00 0.00 0.00 1.00 0.00 8.00 8.00 0.00 0.00 0.00 0.00 0.00 0.00
md0 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
md127 0.00 0.00 0.00 29.33 0.00 312.00 10.64 0.00 0.00 0.00 0.00 0.00 0.00
drbd5 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
drbd3 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
drbd4 0.00 0.00 0.00 8.67 0.00 77.33 8.92 2.03 230.96 0.00 230.96 26.12 22.63
dm-0 0.00 0.00 0.00 29.67 0.00 317.33 10.70 5.11 171.56 0.00 171.56 23.91 70.93
dm-1 0.00 0.00 0.00 8.67 0.00 77.33 8.92 2.03 230.96 0.00 230.96 26.12 22.63
dm-2 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
dm-3 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
dm-4 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
dm-5 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
dm-6 0.00 0.00 0.00 20.00 0.00 240.00 12.00 3.03 151.55 0.00 151.55 31.33 62.67
dm-7 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
dm-8 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
dm-9 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
dm-10 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
dm-11 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据我所知,/dev/sda和/dev/sdb在await (2ms vs 27 my )和%util (7% vs 92%)之间有显着性差异。这些驱动器是彼此的镜像,是同样重要的M500 SSD,所以我不明白这是怎么可能的。/dev/sda上没有任何活动也不应该发生在/dev/sdb上。
我经常检查这两个磁盘的智能值,我注意到Percent_Lifetime_Used for /dev/sda表示使用了66%,而/dev/sdb报告了一个无意义的值(使用了454%)。到目前为止,我一直不太担心,因为Reallocated_Event_Count在这两个驱动器上都保持相对较低的水平,并且没有迅速改变。
我们的/dev/sdb磁盘可能有硬件问题吗?还有其他可能的解释吗?
发布于 2017-09-16 01:26:15
我最终发现这个系统不是正确的TRIMed,而且分区时也没有足够的过度配置(尽管关键的M500有7%的2个级超额供应内置)。两者的结合导致了一个严重的写放大病例。
此外,该系统包含一个具有非常高的写入活动的数据库,导致大量的小随机写入。这种IO活动有一个具有写放大功能的非常糟糕的结果。
我仍然不能百分之百地确定为什么/dev/sda在iostat上的表现要好于/dev/sdb --也许是类似于硅彩票,/dev/sda略优于/dev/sdb,所以/dev/sdb首先遇到瓶颈。
对我们来说,主要的两种方法是:
https://serverfault.com/questions/871096
复制相似问题