我正在使用 hdparm -t 对 PV(sda3 和 sdb2)和 LV(工作)进行测量。实际上,PV 上的速度更快。
这真的只是 lvm 的方式吗,还是我做错了什么?
# lvs -a -o +devices
LV VG Attr LSize Origin Snap% Move Log Copy% Convert Devices
root foobar -wi-ao 165.00G /dev/sda3(10752)
swap foobar -wi-ao 2.00G /dev/sda3(10240)
work foobar mwi-ao 148.52G work_mlog 100.00 work_mimage_0(0),work_mimage_1(0)
[work_mimage_0] foobar iwi-ao 148.52G /dev/sda3(52992)
[work_mimage_1] foobar iwi-ao 148.52G /dev/sdb2(0)
[work_mlog] foobar lwi-ao 4.00M /dev/sdb1(0)
答案1
通过额外的虚拟块设备接口(在内核中)传递数据会产生少量额外开销。通常它与线路噪声相当(不超过 3%)。
如果您希望提高多个驱动器的性能,则需要查看 md(元磁盘)驱动程序... RAID 1(镜像)或 RAID 10(镜像 + 条带化)。在这些情况下,您的系统可能能够同时交错读取和写入多个驱动器(主轴)。(请注意,有些硬件配置不会从镜像中受益;例如,两个驱动器挂在普通的旧 IDE/PATA 电缆上;一个控制器/电缆是瓶颈)。
影响整体驱动器性能的两个主要因素是寻道时间和吞吐量……将驱动器磁头定位到请求的数据上需要多长时间以及数据通过电缆传输的速度有多快。通过两个 I/O 通道进行镜像显然可以提高读吞吐量(可能几乎是任何给定间隔内传输数据的两倍)。对寻道时间的影响是巨大的,而且更具概率性……两个驱动器上的磁头可能位于各自盘片的不同部分。读取请求可以来自任一驱动器,因此请求可以被路由到碰巧磁头更靠近所需区域的驱动器。(据我所知,这实际上只是通过 Linux 内核中的粗略启发式方法完成的……驱动程序不知道驱动器几何结构的细节,而只是将请求视为“线性块阵列”表中的偏移量)。
更重要的是,镜像 RAID 配置可以同时满足多个读取请求。
请注意,RAID 镜像对写入没有任何好处。每次写入都必须在多个驱动器上进行...因此,它必须通过该组中的每个 I/O 通道进行传输,并且您会遭受该组中最糟糕的寻道时间(而不是在读取时从最佳位置的磁头中获益)。
请注意,在 Linux 中可以同时使用 LVM 和 md RAID 功能。通常,您会将 md* 驱动程序用作较低的虚拟块层(将物理磁盘聚合到 RAID 集中),然后在这些驱动器上使用 LVM(将每个顶层 md*(1、5 或 6)设备变成 LVM PV --- 物理卷)。在大多数情况下,我认为 RAID 0(条带化)对于 LVM 毫无意义。(LVM 可以将多个驱动器聚合到更大的虚拟卷中,就像 RAID 0 一样。但是它更灵活)。
答案2
我曾经遇到的一个问题是,对于 LVM 卷,最大预读的默认值设置得太低了。据我所知,这个问题已经修复了,但我想检查一下也没什么坏处。例如
blockdev --getra /dev/foo/bar
查看设备的预读设置,然后 --setra N 将其设置为 N 个扇区。您可能希望在底层设备或 LVM 卷上设置适当的预读,而不是同时设置两者。
此外,为了进行“正确”的基准测试,请使用 iozone、fio、bonnie++ 之类的程序,而不是 hdparm。hdparm 直接访问驱动器,而且我不确定当您在虚拟设备(例如 LVM LV)上运行它时它是否会执行任何相关操作。
答案3
这可能有很多原因。我知道某些文件系统具有“写时复制”功能,包括 Ext3、ZFS、WAFL、VERITAS (NetBackup) 和 btrfs。然而,虽然写时复制 (COW) 可能会减慢您的系统速度,但它不应该是容易被注意到的。
此外,如果您启用了快照(使用任何控制器来创建 LV),这也会降低它们的速度。
根据卷中物理盘区的大小,它可能会减慢速度(例如,也许每个物理驱动器的总卷不同)。或者也许组成 LVM 的某个物理磁盘出了问题。
尝试对磁盘本身进行一些诊断,看看是否有任何磁盘返回坏扇区/片。您是否自动增大此逻辑卷,或者这是一个固定大小的卷?
这很可能是 LVM 镜像的设置方式。控制器或物理磁盘可能存在问题。您还必须记住控制器的速度,因为数据到达驱动器的路径要经过控制器 - 较旧的控制器与较新的 HDD 搭配使用并不能加快速度(取决于较旧的控制器,我有一个很旧的控制器,但几乎总是比一些较新的控制器性能更好)。