[linux][block]readahead导致的md-raid1读速度慢问题

前言 为了提高虚拟机的网盘的高科用，同时挂载了两块，在Guest内部使用RAID1，如果后端一块发生故障，可以保证在10s内failover，恢复业务运行。当前的配置是把RAID1的md设备格式化成ext4文件系统，挂载后使用。 atop每天大约生成了200M+的文件，文件在md设备上。发现在查看atop文件的时候，耗时很长，大约估计需要30s。 分析 1,使用filemap分析文件的物理分布 首先怀疑是ext4的文件在物理分布上的情况，有可能是比较零碎，会导致读消耗更高的IOPS。 作者写过一个工具，用来dump出来文件的物理layout情况，代码路径： https://github.com/pacepi/tool/blob/master/filemap.c 编译后执行，

可见，物理的分布情况比较连续，普遍比较大块。所以可以排除ext4的问题。 2,测试md设备的bandwidth 清空page cahce，测试从md设备的读性能：

发现读性能只有13.5M/s，远远低于预期。block size在4M的情况下，普通的HDD盘基本读性能在120M/s～180M/s。及时经过网络一次，也预期在100M/s左右。 对比实验，使用direct IO， #dd if=/dev/md0 of=/dev/null bs=4M count=10 iflag=direct 发现读性能接近100M/s。 继续对比实验，测试写性能， #dd if=/dev/zero of=/var/log/atop/tmp bs=4M count=10 oflag=sync 发现写性能接近100M/s 可见，设备的IO能力似乎不是瓶颈，应该出现在了ext4到md设备之间的处理上，尤其是带有page cache的情况。 3,验证md的request 使用dd复现问题的同时，使用观察iostat，发现io单次请求的数据量比较小。

结合linxu/drivers/md/raid1.c的代码来看，怀疑从上面下来的请求比较小。 使用systemtap是比较好的选择，但是需要安装更多的东西。于是使用了朴素一点的办法，把当前版本的md目录下的代码copy到机器上，修改Makefile。使用printk把max_read_sectors打印出来。编译出来kmod后： echo 3 > /proc/sys/vm/drop_caches mdadm --stop /dev/md0 rmmod raid1 rmmod raid10 rmmod raid0 rmmod linear rmmod raid456 rmmod multipath rmmod md_mod insmod md-mod.ko insmod raid1.ko mdadm --create /dev/md0 --level=1 --raid-devices=2 --metadata=1.2 --assume-clean /dev/sdc /dev/sdd 发现max_read_sectors的请求值256,每个sector是512 bytes，所以每次请求就是128K。 4,io trace 使用strace分析发现，dd命令确实读请求是4M，但是到了raid1之后，就变成了单次请求128K。所以需要分析调用栈，是哪里处理的结果。 kernel中提供了dump_stack()函数。重新编译加载kmod，可以看到如下trace： [ 6891.519793] CPU: 20 PID: 27203 Comm: dd Tainted: G O 4.14.81.bm.7-amd64 #1 [ 6891.519793] Hardware name: ByteDance Inc. ByteVM, BIOS rel-1.11.1-0-g0551a4be2c-prebuilt.qemu-project.org 04/01/2014 [ 6891.519794] Call Trace: [ 6891.519797] dump_stack+0x5c/0x85 [ 6891.519799] raid1_read_request+0x9a3/0x9e0 [raid1] [ 6891.519801] ? kmem_cache_alloc+0x11a/0x5a0 [ 6891.519803] ? mempool_alloc+0x64/0x190 [ 6891.519804] raid1_make_request+0x6c/0x90 [raid1] [ 6891.519807] md_handle_request+0x110/0x180 [md_mod] [ 6891.519810] md_make_request+0x65/0x160 [md_mod] [ 6891.519812] generic_make_request+0x11e/0x2f0 [ 6891.519813] ? submit_bio+0x6c/0x140 [ 6891.519815] submit_bio+0x6c/0x140 [ 6891.519816] ? guard_bio_eod+0x26/0xe0 [ 6891.519817] mpage_readpages+0x164/0x1a0 [ 6891.519818] ? I_BDEV+0x10/0x10 [ 6891.519819] ? __alloc_pages_nodemask+0xfa/0x250 [ 6891.519821] __do_page_cache_readahead+0x201/0x2e0 [ 6891.519824] ? ondemand_readahead+0x171/0x2b0 [ 6891.519825] ondemand_readahead+0x171/0x2b0 [ 6891.519827] generic_file_read_iter+0x75a/0x9e0 [ 6891.519829] ? page_cache_tree_insert+0xc0/0xc0 [ 6891.519830] __vfs_read+0xf6/0x160 [ 6891.519831] vfs_read+0x91/0x130 [ 6891.519832] SyS_read+0x52/0xc0 [ 6891.519833] do_syscall_64+0x68/0x100 [ 6891.519835] entry_SYSCALL_64_after_hwframe+0x3d/0xa2 [ 6891.519836] RIP: 0033:0x7f8c66b6b6d0 [ 6891.519836] RSP: 002b:00007ffc152b2f68 EFLAGS: 00000246 ORIG_RAX: 0000000000000000 [ 6891.519837] RAX: ffffffffffffffda RBX: 00005608f8894400 RCX: 00007f8c66b6b6d0 [ 6891.519838] RDX: 0000000000400000 RSI: 00007f8c6668e000 RDI: 0000000000000000 [ 6891.519838] RBP: 0000000000400000 R08: ffffffffffffffff R09: 0000000000000000 [ 6891.519839] R10: 000000000000037b R11: 0000000000000246 R12: 00007f8c6668e000 [ 6891.519840] R13: 0000000000000000 R14: 0000000000000000 R15: 0000000000000000 5,使用kprobe 分析特定的函数的参数，使用kprobe进行分析。例如怀疑 ondemand_readahead函数：

例如怀疑参数的struct file_ra_state *ra和req_size，那么可以写如下代码：

需要注意的是，x86 64的函数调用，如果参数不大于6,那么6个参数分别通过di,si,dx,cx,r8,r9传递。所以ra作为第2个参数，放在了si中;req_size作为第6个参数，就是r9。 6,read_ahead_kb 结合上文的trace和kprobe的信息，最终发现md设备有自己的readahead size，且默认值是128K。 #cat /sys/block/md0/queue/read_ahead_kb 可以确认默认值是128。 #echo 1024 > /sys/block/md0/queue/read_ahead_kb 修改readahead的大小。

修改后，读速度达到预期。