Evg*_*hov 5 linux raid storage ssd software-raid
我的服务器配备 Supermicro X10DRW-i 主板和 8 个 KINGSTON SKC400S SSD 的 RAID10 阵列;操作系统是 CentOS 6
# cat /proc/mdstat
Personalities : [raid10] [raid1]
md2 : active raid10 sdj3[9](S) sde3[4] sdi3[8] sdd3[3] sdg3[6] sdf3[5] sdh3[7] sdb3[1] sda3[0]
3978989568 blocks super 1.1 512K chunks 2 near-copies [8/8] [UUUUUUUU]
bitmap: 9/30 pages [36KB], 65536KB chunk
Run Code Online (Sandbox Code Playgroud)
—
# mdadm --detail /dev/md2
/dev/md2:
Version : 1.1
Creation Time : Wed Feb 8 18:35:14 2017
Raid Level : raid10
Array Size : 3978989568 (3794.66 GiB 4074.49 GB)
Used Dev Size : 994747392 (948.67 GiB 1018.62 GB)
Raid Devices : 8
Total Devices : 9
Persistence : Superblock is persistent
Intent Bitmap : Internal
Update Time : Fri Sep 14 15:19:51 2018
State : active
Active Devices : 8
Working Devices : 9
Failed Devices : 0
Spare Devices : 1
Layout : near=2
Chunk Size : 512K
Name : ---------:2 (local to host -------)
UUID : 8a945a7a:1d43dfb2:cdcf8665:ff607a1b
Events : 601432
Number Major Minor RaidDevice State
0 8 3 0 active sync set-A /dev/sda3
1 8 19 1 active sync set-B /dev/sdb3
8 8 131 2 active sync set-A /dev/sdi3
3 8 51 3 active sync set-B /dev/sdd3
4 8 67 4 active sync set-A /dev/sde3
5 8 83 5 active sync set-B /dev/sdf3
6 8 99 6 active sync set-A /dev/sdg3
7 8 115 7 active sync set-B /dev/sdh3
9 8 147 - spare /dev/sdj3
Run Code Online (Sandbox Code Playgroud)
我注意到写入速度很糟糕,甚至不接近 SSD 的性能。
# dd if=/dev/zero of=/tmp/testfile bs=1G count=1 oflag=dsync
1+0 records in
1+0 records out
1073741824 bytes (1.1 GB) copied, 16.511 s, 65.0 MB/s
Run Code Online (Sandbox Code Playgroud)
不过读取速度还可以
# hdparm -tT /dev/md2
/dev/md2:
Timing cached reads: 20240 MB in 1.99 seconds = 10154.24 MB/sec
Timing buffered disk reads: 3478 MB in 3.00 seconds = 1158.61 MB/sec
Run Code Online (Sandbox Code Playgroud)
在对该问题进行了一些故障排除后,我发现最初可能是我弄乱了存储配置:X10DRW-i 有 Intel C610,它有两个独立的 SATA 控制器,6 端口 SATA 和 4 端口 sSATA。所以阵列中的磁盘连接到不同的控制器,我认为这是性能不佳的根本原因。我只有一个解决这个问题的想法:安装 PCIe SAS 控制器(可能是 AOC-S3008L-L8E)并将 SSD 驱动器连接到它。
所以我想确认以下几点:
我对根本原因是否正确,或者我应该仔细检查一些东西?
我的解决方案会奏效吗?
如果我将驱动器重新连接到新控制器,我的 RAID 和数据是否会继续存在?我的研究表明是的,因为分区的 UUID 将保持不变,但我只想确定。
提前感谢大家。
UPD:iostat -x 1
在执行 dd 测试时:https : //pastebin.com/aTfRYriU
# hdparm /dev/sda
/dev/sda:
multcount = 16 (on)
IO_support = 1 (32-bit)
readonly = 0 (off)
readahead = 256 (on)
geometry = 124519/255/63, sectors = 2000409264, start = 0
Run Code Online (Sandbox Code Playgroud)
—
# cat /sys/block/md2/queue/scheduler
none
Run Code Online (Sandbox Code Playgroud)
虽然 AFAIK 调度程序设置在物理驱动器上:
# cat /sys/block/sda/queue/scheduler
noop anticipatory [deadline] cfq
Run Code Online (Sandbox Code Playgroud)
—
smartctl -a
(在设备上,而不是分区):https : //pastebin.com/HcBp7gUH
UPD2:
# dd if=/dev/zero of=/tmp/testfile bs=1M count=1024 oflag=direct
1024+0 records in
1024+0 records out
1073741824 bytes (1.1 GB) copied, 14.389 s, 74.6 MB/s
Run Code Online (Sandbox Code Playgroud)
UPD3:
我刚刚fstrim
在/分区上运行并得到了一些效果,但在连续五次测试中写入速度仍然太低:227 MB / s,162 MB / s,112 MB / s,341 MB / s,202 MB / s。
sho*_*hok 10
测得的低性能是多种因素的结果:
fstrim
;之后性能的提高。dd
)。对于全 SSD 阵列,我会选择 64 KB 的块大小,并且可能(但这应该通过实际测试来确认)使用“远”布局。请注意,减小块大小虽然有利于流访问,但会惩罚随机读/写。这主要是 HDD 的问题,但即使是 SSD 也会受到一定影响;dd
使用 1 GB 块(根据您的第一个命令),这些块也会被拆分为无数 512 KB 大小的请求。再加上您的 512 KB 大小的块,这将为每个写入请求占用一个SSD,基本上将流写入性能限制在单个 SSD 级别,并拒绝由于 RAID 带来的任何潜在速度提升。虽然您可以使用max_sectors_kb
可调参数(在 中找到/sys/block/sdX/queue/max_sectors_kb
),但可以忽略大于 512 KB 的值(在某些配置/内核版本中);dd
它本身是一个糟糕的基准测试:它仅测试低 (1) 队列深度的流性能。即使使用您当前的阵列配置,更全面的测试fio
也会显示相对于单磁盘方案的显着性能提升,至少在随机 I/O 中是这样。你能做些什么来纠正目前的情况?首先,您必须接受擦除磁盘/阵列;显然,您需要将备份作为第一步。然后:
mdadm -S /dev/md2
)blkdiscard /dev/sdX3
mdadm --create /dev/md2 --level=10 --raid-devices=8 --chunk=64 --assume-clean /dev/sdX3
)重新创建数组dd
和重新工作fio
;关于 SATA 设置的最后一个注意事项:显然应该避免以这种方式分割磁盘以获得最大性能。也就是说,你的写入速度太低了,我不会责怪你的 SATA 控制器。在购买任何新东西之前,我真的会按照上述说明重新创建数组。