笔记:我在这里看到过一些类似的问题,但是:
- 它们都不涉及并行读取多个文件,并且
- 大多数已有 10 多年的历史,并且涉及不再相关的硬件和内核版本。
背景:
我有一台 Linux 机器(Ubuntu,内核 5.15.0-82-generic),有两个 128 核 CPU 和 128 GB RAM。它有一个 RAID 5 阵列,由 10 个通过 SATA 连接的 SSD 组成,每个 SSD 的额定读取速度最高为 530 MB/s。这些 SSD 在使用时实际上是只读的(它们主要在白天使用,每晚都会添加新数据)。我通常的问题是并行为数十个核心提供磁盘数据。
基准测试程序
我通过运行以下实例来对读取进行基准测试
dd if=/path/to/large/file of=/dev/null bs=1024 count=1048576
与iostat
和并行iotop
。在运行之间,我通过运行来清除缓存
sudo sh -c "sync; echo 3 > /proc/sys/vm/drop_caches"
我确信这可以正常工作,因为如果我不这样做,那么对热文件的后续读取几乎会立即完成,然后一旦我这样做,读取该文件就会回到与以前相同的性能。
基准测试结果
如果我通过软件 RAID 读取单个文件,我会得到 500 - 700 MB/s 之间的读取速率,查看输出我iostat
发现实现这一点的方式是从十个驱动器中的每一个驱动器以基本上完全相同的速度并行读取。
如果我直接从驱动器读取(即如果我提供/dev/sda
、/dev/sdb
等作为if=
的参数dd
),那么我就能够以每个 530MB/s 的速度并行读取每个驱动器(即从所有十个驱动器读取 1GB 所需的时间与从其中一个驱动器读取 1GB 所需的时间完全相同。)
但是,如果我尝试通过软件 RAID 并行读取多个文件,性能会大幅下降。如果我通过软件 RAID 并行读取十个文件,那么单个文件的读取速度在 150 到 350 MB/s 之间,整个过程所需的时间是直接从驱动器复制相同数量数据的 4 倍。
此外,据 iotop 报告,软件读取似乎遇到了绝对瓶颈,总读取速度约为 2.7 GB/s。
我认为为了向所有核心提供足够的磁盘数据以免浪费,我可能需要转向 NVMe 而不是 SATA,但我想先解决这个问题,因为似乎软件 RAID 或其上游的某些东西限制了我从这些磁盘读取的速度。
问题:
- 我如何诊断瓶颈在哪里?
- 我如何查看这里的配置选项,我还有哪些其他选项?
- 我的设置是否存在根本限制,导致我所尝试的操作无法完成?如果是,我可以使用其他配置吗?
我已经尝试过的东西
- 调整块大小
dd
,使其变大或变小,都没有效果。 - 设置 RAID 预读和/或条带缓存大小无效
- 将内核升级到稍新的版本会极大地损害基准测试结果,基本上将总吞吐量限制在 500 MB/s IIRC。
附录:
iostat -k 1
基准测试运行期间的示例输出:https://pastebin.com/yuWwWbRU
内容/proc/mdstat
:
Personalities : [raid6] [raid5] [raid4] [linear] [multipath] [raid0] [raid1] [raid10]
md127 : active raid5 sdj1[10] sdh1[7] sdi1[8] sdf1[5] sdd1[3] sdc1[2] sdg1[6] sde1[4] sdb1[1] sda1[0]
70325038080 blocks super 1.2 level 5, 4k chunk, algorithm 2 [10/10] [UUUUUUUUUU]
bitmap: 0/59 pages [0KB], 65536KB chunk
unused devices: <none>