所以，我有一个3.5TB MySQL数据库的服务器与每个表innodb文件。 它有4个磁盘RAID 10组中的24个2.5“10K HDs，通过vmware ESXi连接成1TB数据存储，全部6个LVM分为一个6TB ext3磁盘
现在，我正在做一个
sudo e2fsck -f /dev/vg1/lv1 之前
sudo resize2fs /dev/vg1/lv1
这里是iostat -x 5的结果：
Device: rrqm/s wrqm/sr/sw/s rsec/s wsec/s avgrq-sz avgqu-sz await svctm %util sda 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 sdb 0.00 0.00 33.40 0.00 267.20 0.00 8.00 0.17 5.15 5.15 17.20 sdc 0.00 0.00 36.20 0.00 289.60 0.00 8.00 0.14 3.76 3.76 13.60 sdd 0.00 0.00 33.20 0.00 265.60 0.00 8.00 0.14 4.28 4.28 14.20 sde 0.00 0.00 35.80 0.00 286.40 0.00 8.00 0.18 5.14 5.14 18.40 sdf 0.60 0.00 32.80 0.00 267.20 0.00 8.15 0.18 5.37 5.37 17.60 sdg 0.00 0.00 35.60 0.00 284.80 0.00 8.00 0.19 5.22 5.22 18.60 dm-0 0.00 0.00 207.60 0.00 1660.80 0.00 8.00 1.00 4.80 4.80 99.60 dm-1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 dm-2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
我已经通过在这里和谷歌关于LVM性能的其他post看过，没有一个真正给我足够的信息来诊断LVM是否会瓶颈IO的磁盘。 在这里，看起来dm-0在％util中最大，而实际的磁盘％util都在十几岁。
有什么我可以做的，以解决这个问题？ 条纹两次，这是RAID 1000而不是我的RAID 100？ iostat是否错误地报告了LVM？
我在几个月前完成了这个工作，但这是我所做的：
对于需要快速恢复联机的大型磁盘上的e2fsck问题，只需跳过即可。 由于resize2fs在磁盘未挂载的情况下强制使用e2fsck，只需将其挂载并让resize2fs在线调整lvm分区的大小即可。
至于设备映射瓶颈问题，iostat似乎没有意识到该分区被剥离（添加％utils是99.3％）和unix.stackexchange上的一个post保证lvm / dm不会影响性能（除了在lvm磁盘快照期间，无论如何你都应该使用xtrabackup和–throttle = IOPS进行mysql备份）。