我觉得我对当前的服务器设置有点迷茫。它是 HP Proliant dl160 gen 6,我安装了 4 个旋转磁盘,其设置有 mdmadm + luks + lvm,并在其上安装了 btrfs(也许我做得太过了?),它的 IO 速度真的很差,读取速度约为 50MB/s,写入速度约为 2MB/s,我感觉我搞砸了一些东西。
我注意到的一件事是,我在块设备(sbd)上设置了 mdadm,而不是在分区(sdb1)上设置,这会影响什么吗?
fio --name=randwrite --rw=randwrite --direct=1 --bs=16k --numjobs=128 --size=200M --runtime=60 --group_reporting
这里可以看到当机器上几乎没有使用fio时的输出。
randwrite: (groupid=0, jobs=128): err= 0: pid=54290: Tue Oct 26 16:21:50 2021
write: IOPS=137, BW=2193KiB/s (2246kB/s)(131MiB/61080msec); 0 zone resets
clat (msec): min=180, max=2784, avg=924.48, stdev=318.02
lat (msec): min=180, max=2784, avg=924.48, stdev=318.02
clat percentiles (msec):
| 1.00th=[ 405], 5.00th=[ 542], 10.00th=[ 600], 20.00th=[ 693],
| 30.00th=[ 760], 40.00th=[ 818], 50.00th=[ 860], 60.00th=[ 927],
| 70.00th=[ 1011], 80.00th=[ 1133], 90.00th=[ 1267], 95.00th=[ 1452],
| 99.00th=[ 2165], 99.50th=[ 2232], 99.90th=[ 2635], 99.95th=[ 2769],
| 99.99th=[ 2769]
bw ( KiB/s): min= 3972, max= 4735, per=100.00%, avg=4097.79, stdev= 1.58, samples=8224
iops : min= 132, max= 295, avg=248.40, stdev= 0.26, samples=8224
lat (msec) : 250=0.04%, 500=2.82%, 750=25.96%, 1000=40.58%, 2000=28.67%
lat (msec) : >=2000=1.95%
cpu : usr=0.00%, sys=0.01%, ctx=18166, majf=0, minf=1412
IO depths : 1=100.0%, 2=0.0%, 4=0.0%, 8=0.0%, 16=0.0%, 32=0.0%, >=64=0.0%
submit : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
complete : 0=0.0%, 4=100.0%, 8=0.0%, 16=0.0%, 32=0.0%, 64=0.0%, >=64=0.0%
issued rwts: total=0,8372,0,0 short=0,0,0,0 dropped=0,0,0,0
latency : target=0, window=0, percentile=100.00%, depth=1
Run status group 0 (all jobs):
WRITE: bw=2193KiB/s (2246kB/s), 2193KiB/s-2193KiB/s (2246kB/s-2246kB/s), io=131MiB (137MB), run=61080-61080msec
使用 dd 更新 1 次顺序写入
root@hp-proliant-dl160-g6-1:~# dd if=/dev/zero of=disk-test oflag=direct bs=512k count=100
100+0 records in 100+0 records out 52428800 bytes (52 MB, 50 MiB) copied, 5.81511 s, 9.0 MB/s
内核:5.4.0-89-generic
操作系统:Ubuntu 20.04.3
mdadm:4.1-5ubuntu1.2
lvm2:2.03.07-1ubuntu1
blkid 输出
/dev/mapper/dm_crypt-0: UUID="r7TBdk-1GZ4-zbUh-007u-BfuP-dtis-bTllYi" TYPE="LVM2_member"
/dev/sda2: UUID="64528d97-f05c-4f34-a238-f7b844b3bb58" UUID_SUB="263ae70e-d2b8-4dfe-bc6b-bbc2251a9f32" TYPE="btrfs" PARTUUID="494be592-3dad-4600-b954-e2912e410b8b"
/dev/sdb: UUID="478e8132-7783-1fb1-936a-358d06dbd871" UUID_SUB="4aeb4804-6380-5421-6aea-d090e6aea8a0" LABEL="ubuntu-server:0" TYPE="linux_raid_member"
/dev/sdc: UUID="478e8132-7783-1fb1-936a-358d06dbd871" UUID_SUB="9d5a4ddd-bb9e-bb40-9b21-90f4151a5875" LABEL="ubuntu-server:0" TYPE="linux_raid_member"
/dev/sdd: UUID="478e8132-7783-1fb1-936a-358d06dbd871" UUID_SUB="f08b5e6d-f971-c622-cd37-50af8ff4b308" LABEL="ubuntu-server:0" TYPE="linux_raid_member"
/dev/sde: UUID="478e8132-7783-1fb1-936a-358d06dbd871" UUID_SUB="362025d4-a4d2-8727-6853-e503c540c4f7" LABEL="ubuntu-server:0" TYPE="linux_raid_member"
/dev/md0: UUID="a5b5bf95-1ff1-47f9-b3f6-059356e3af41" TYPE="crypto_LUKS"
/dev/mapper/vg0-lv--0: UUID="6db4e233-5d97-46d2-ac11-1ce6c72f5352" TYPE="swap"
/dev/mapper/vg0-lv--1: UUID="4e1a5131-cb91-48c4-8266-5b165d9f5071" UUID_SUB="e5fc407e-57c2-43eb-9b66-b00207ea6d91" TYPE="btrfs"
/dev/loop0: TYPE="squashfs"
/dev/loop1: TYPE="squashfs"
/dev/loop2: TYPE="squashfs"
/dev/loop3: TYPE="squashfs"
/dev/loop4: TYPE="squashfs"
/dev/loop5: TYPE="squashfs"
/dev/loop6: TYPE="squashfs"
/dev/loop7: TYPE="squashfs"
/dev/loop8: TYPE="squashfs"
/dev/loop9: TYPE="squashfs"
/dev/loop10: TYPE="squashfs"
/dev/sda1: PARTUUID="fa30c3f5-6952-45f0-b844-9bfb46fa0224"
猫/proc/mdstat
Personalities : [raid6] [raid5] [raid4] [linear] [multipath] [raid0] [raid1] [raid10]
md0 : active raid5 sdb[0] sdc[1] sdd[2] sde[4]
5860147200 blocks super 1.2 level 5, 512k chunk, algorithm 2 [4/4] [UUUU]
bitmap: 2/15 pages [8KB], 65536KB chunk
unused devices: <none>
lshw -c 磁盘
*-disk
description: SCSI Disk
product: DT 101 G2
vendor: Kingston
physical id: 0.0.0
bus info: scsi@0:0.0.0
logical name: /dev/sda
version: 1.00
serial: xxxxxxxxxxxxxxxxxxxx
size: 7643MiB (8015MB)
capabilities: removable
configuration: ansiversion=4 logicalsectorsize=512 sectorsize=512
*-medium
physical id: 0
logical name: /dev/sda
size: 7643MiB (8015MB)
capabilities: gpt-1.00 partitioned partitioned:gpt
configuration: guid=6c166e3e-27c9-4edf-9b0d-e21892cbce41
*-disk
description: ATA Disk
product: ST2000DM008-2FR1
physical id: 0.0.0
bus info: scsi@1:0.0.0
logical name: /dev/sdb
version: 0001
serial: xxxxxxxxxxxxxxxxxxxx
size: 1863GiB (2TB)
capabilities: removable
configuration: ansiversion=5 logicalsectorsize=512 sectorsize=4096
*-medium
physical id: 0
logical name: /dev/sdb
size: 1863GiB (2TB)
*-disk
description: ATA Disk
product: ST2000DM008-2FR1
physical id: 0.0.0
bus info: scsi@2:0.0.0
logical name: /dev/sdc
version: 0001
serial: xxxxxxxxxxxxxxxxxxxx
size: 1863GiB (2TB)
capabilities: removable
configuration: ansiversion=5 logicalsectorsize=512 sectorsize=4096
*-medium
physical id: 0
logical name: /dev/sdc
size: 1863GiB (2TB)
*-disk
description: ATA Disk
product: WDC WD20EZBX-00A
vendor: Western Digital
physical id: 0.0.0
bus info: scsi@3:0.0.0
logical name: /dev/sdd
version: 1A01
serial: xxxxxxxxxxxxxxxxxxxx
size: 1863GiB (2TB)
capabilities: removable
configuration: ansiversion=5 logicalsectorsize=512 sectorsize=4096
*-medium
physical id: 0
logical name: /dev/sdd
size: 1863GiB (2TB)
*-disk
description: ATA Disk
product: WDC WD20EZBX-00A
vendor: Western Digital
physical id: 0.0.0
bus info: scsi@4:0.0.0
logical name: /dev/sde
version: 1A01
serial: xxxxxxxxxxxxxxxxxxxx
size: 1863GiB (2TB)
capabilities: removable
configuration: ansiversion=5 logicalsectorsize=512 sectorsize=4096
*-medium
physical id: 0
logical name: /dev/sde
size: 1863GiB (2TB)
您是否发现设置中可能存在任何错误?您认为添加带有 PCI 卡的 nvme 并将其用于缓存会有帮助吗?
答案1
糟糕的录制表现源于不同的因素:
机械磁盘在随机读写 IO 方面表现非常糟糕。要发现多么糟糕可以,只需附加
--sync=1
到你的fio
命令即可(简而言之:它们是难以置信糟糕,至少与适当的 BBU RAID 控制器或断电保护 SSD 相比);由于条带读取/修改/写入,RAID5 具有固有的写入损失。此外,强烈建议避免出于安全原因,请勿将其安装在多 TB 机械磁盘上。如果有 4 个磁盘,请认真考虑使用 RAID10;
LUKS 提供基于软件的全盘加密,不可避免地会对读取和写入造成(重大)损失;
使用 BTRFS,LVM 完全没有必要。虽然基于 LVM 的胖卷本身不会以任何有意义的方式损害性能,但您仍然会插入另一个 IO 层并面临(更多)对齐问题;
最后,BTRFS 本身并不是特别快。尤其是你的慢速顺序读取可以追溯到 BTRFS 可怕的碎片(因为它是 CoW和强制执行 4K 粒度 - 作为比较,为了从 ZFS 获得良好的性能,在使用机械磁盘时通常应该选择 64K-128K 记录)。
为了进行基准性能比较,我强烈建议重新执行 IO 堆栈,测量每一步的随机和顺序读/写速度。换句话说:
创建 RAID10 阵列并
dd
在fio
原始阵列(没有文件系统)上运行;如果确实需要全盘加密,请使用 LUKS 创建加密设备并在原始加密设备上重新运行
dd
+fio
(同样,没有文件系统)。与之前的结果进行比较,以了解其对性能的影响;尝试两个都XFS 和 BTRFS(运行常规
dd
+fio
快速基准)以了解两种不同的文件系统的行为方式。如果 BTRFS 太慢,请尝试将其替换为叶酸和 XFS(但请记住,在这种情况下,您将丢失用户数据校验和,因此您还需要另一层 -完整性- 本身会造成显著的性能损失)。
如果这一切看起来一团糟,好吧,事实确实如此。通过执行上述所有操作,您只是在刮擦存储性能:必须考虑实际的应用程序行为(而不是完全连续dd
或纯随机的fio
结果)、缓存命中率、IO 模式对齐等。但是嘿 -很少比没有什么,所以让我们从一些基础的东西开始。
答案2
这是一个老问题,但我遇到了同样的问题并找到了正确的答案这里。希望这能帮助到其他人。
总而言之,您需要增加stripe_cache_size
。这可以通过以下方式完成:
echo 16384 > /sys/block/md0/md/stripe_cache_size
确保指向正确的 mdadm 卷。您可以尝试上面链接的答案中讨论的各种值,我使用这个获得了最好的结果。
答案3
简而言之:我认为你的问题可能是你的基准测试使用的是随机写入比 RAID 块大小小得多。
您在使用系统时是否注意到了性能问题?或者,只是基准测试结果看起来很糟糕?对于具有大 512K 块的 RAID 5,16K 随机写入基准测试接近最坏情况。
RAID 5 有一个必须与数据一起更新的奇偶校验块。如果您有一个连续的工作负载,内核可以将其分解为 512K 写入,那么您只需计算新的奇偶校验信息,然后写出数据块和奇偶校验块。一次写入相当于两次写出。
但是,对于比块大小小得多的 16K 写入,您必须先读取旧数据和旧奇偶校验,然后计算新奇偶校验信息,然后写出新数据和奇偶校验。这就是读-读-写-写。一次写入相当于四次 I/O。对于随机写入,即使是世界上最好的 RAID 控制器也无法预测要缓存哪些块。
如果您使用数组来存储大型文件,那么您很幸运:您只是使用了错误的基准来评估其性能。如果您在基准中randwrite
简单地更改write
为按顺序写入,那么它应该会变得更好!
但是,如果您的工作负载确实由更多随机、小写入组成,那么您将不得不对阵列进行一些更改。4 磁盘 RAID 10 更适合您。但这仍然是旋转介质。它不会震撼您的世界。我猜想 RAID 10 的性能应该是您现在的 2 倍到 3 倍,大约 275 到 400 IOPS,也许在该基准上为 4MiB/s 到 6MiB/s?
至于使用 SSD 进行缓存,也许使用 bcache 之类的东西,您就可以消除冗余。考虑使用两个 SSD 的 RAID 1 进行缓存?考虑到这些驱动器的速度,您肯定不需要 NVMe。SATA 就足够了。
(顺便说一句,不要担心分区与原始设备。这没什么区别。就我个人而言,我不使用分区。)