标签：node 读取 dd 108 ra IO 253 128 磁盘

在两台型号相同的机器上(snap1 和snap3)测试磁盘的读取速度，发现两台机器的读取速度差的很大:

1. #dd if=/dev/dm-93 of=/dev/null bs=4M count=1024

2. 711MB/s on snap1.

3. 178MB/s on snap3.

接下来比较snap1和snap3两台机器上关于dm-93磁盘(raid)的以下字段输出都是一样

1. /sys/block/<device>/queue/max_sectors_kb

2. /sys/block/<device>/queue/nomerges

3. /sys/block/<device>/queue/rq_affinity

4. /sys/block/<device>/queue/scheduler

5.  

6. 字段解释可以参考：

7. https://www.kernel.org/doc/Documentation/block/queue-sysfs.txt 

然后用blktrace监控一下磁盘IO处理过程:

#blktrace /dev/dm-93

使用blkparse查看blktrace收集的日志：

1. 253,108  1        1     7.263881407 21072  Q   R 128 + 128 [dd]

2. 在snap3上请求读取一页(64k每页）

3. 253,108  1        2     7.263883907 21072  G   R 128 + 128 [dd]

4. 253,108  1        3     7.263885017 21072  I   R 128 + 128 [dd]

5. 253,108  1        4     7.263886077 21072  D   R 128 + 128 [dd]

6. 提交IO到磁盘

7. 253,108  0        1     7.264883548     3  C   R 128 + 128 [0]

8. 大约1ms之后IO处理完成

9. 253,108  1        5     7.264907601 21072  Q   R 256 + 128 [dd]

10. 磁盘处理IO完成之后，dd才开始处理下一个IO

11. 253,108  1        6     7.264908587 21072  G   R 256 + 128 [dd]

12. 253,108  1        7     7.264908937 21072  I   R 256 + 128 [dd]

13. 253,108  1        8     7.264909470 21072  D   R 256 + 128 [dd]

14. 253,108  0        2     7.265757903     3  C   R 256 + 128 [0]

15. 但是在snap1上则完全不同，上一个IO没有完成的情况下，dd紧接着处理下一个IO

16. 253,108 17        1     5.020623706 23837  Q   R 128 + 128 [dd]

17. 253,108 17        2     5.020625075 23837  G   R 128 + 128 [dd]

18. 253,108 17        3     5.020625309 23837  P   N [dd]

19. 253,108 17        4     5.020626991 23837  Q   R 256 + 128 [dd]

20. 253,108 17        5     5.020627454 23837  M   R 256 + 128 [dd]

21. 253,108 17        6     5.020628526 23837  Q   R 384 + 128 [dd]

22. 253,108 17        7     5.020628704 23837  M   R 384 + 128 [dd]

现在怀疑是snap3上读取磁盘数据时没有预读，但是检查两台机器上read_ahead_kb的值都是一样的，都是512. 

1. #/sys/block/<device>/queue/read_ahead_kb

2. 512

3.  

没办法了，发绝招：用kprobe探测一下相关函数参数：

1. #ra_trace.sh

2. #!/bin/bash

3.  

4. if [ "$#" != 1 ]; then

5.     echo "Usage: ra_trace.sh <device>"

6.     exit

7. fi

8. echo 'p:do_readahead __do_page_cache_readahead mapping=%di offset=%dx pages=%cx' >/sys/kernel/debug/tracing/kprobe_events

9. echo 'p:submit_ra ra_submit mapping=%si ra=%di rastart=+0(%di) rasize=+8(%di):u32 rapages=+16(%di):u32' >>/sys/kernel/debug/tracing/kprobe_events

10. echo 'p:sync_ra page_cache_sync_readahead mapping=%di ra=%si rastart=+0(%si) rasize=+8(%si):u32 rapages=+16(%si):u32' >>/sys/kernel/debug/tracing/kprobe_events

11. echo 'p:async_ra page_cache_async_readahead mapping=%di ra=%si rastart=+0(%si) rasize=+8(%si):u32 rapages=+16(%si):u32' >>/sys/kernel/debug/tracing/kprobe_events

12. echo 1 >/sys/kernel/debug/tracing/events/kprobes/enable

13. dd if=$1 of=/dev/null bs=4M count=1024

14. echo 0 >/sys/kernel/debug/tracing/events/kprobes/enable

15. cat /sys/kernel/debug/tracing/trace_pipe&

16. CATPID=$!

17. sleep 3

18. kill $CATPID

发现在snap3上预读磁盘的时候，rasize=0，确实在读数据时没有预读数据。

1.           <...>-35748 [009] 2507549.022375: submit_ra: (.ra_submit+0x0/0x38) mapping=c0000001bbd17728 ra=c000000191a261f0 rastart=df0b rasize=0 rapages=8

2.            <...>-35748 [009] 2507549.022376: do_readahead: (.__do_page_cache_readahead+0x0/0x208) mapping=c0000001bbd17728 offset=df0b pages=0

3.            <...>-35748 [009] 2507549.022694: sync_ra: (.page_cache_sync_readahead+0x0/0x50) mapping=c0000001bbd17728 ra=c000000191a261f0 rastart=df0b rasize=0 rapages=8

4.            <...>-35748 [009] 2507549.022695: submit_ra: (.ra_submit+0x0/0x38) mapping=c0000001bbd17728 ra=c000000191a261f0 rastart=df0c rasize=0 rapages=8

接下来仔细研读一下预读相关的代码，发现预读页与node上的内存相关:  

1. unsigned long max_sane_readahead(unsigned long nr) 

2. {

3.         return min(nr, (node_page_state(numa_node_id(), NR_INACTIVE_FILE)

4.                 + node_page_state(numa_node_id(), NR_FREE_PAGES)) / 2); 

5. }

比较一下snap1与snap3上node上的内存情况，发现snap3上node0上的内存和空闲内存都为0 ( 根因找到 :-)

1. snap1:# /usr/bin/numactl --hardware

2. available: 1 nodes (0)

3. node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

4. node 0 size: 8192 MB

5. node 0 free: 529 MB

6. node distances:

7. node   0

8.   0:  10

9.  

10. snap3:

11. # /usr/bin/numactl --hardware

12. available: 2 nodes (0,2)

13. node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25

14. node 0 size: 0 MB

15. node 0 free: 0 MB

16. node 2 cpus:

17. node 2 size: 8192 MB

18. node 2 free: 888 MB

19. node distances:

20. node   0   2

21.   0:  10  40

22.   2:  40  10

发现内核中有两个patch解决了这个问题，IO的预读不再以当前cpu上node上的内存情况来判断：

1. commit:6d2be915e589

2. mm/readahead.c: fix readahead failure for memoryless NUMA nodes and limit readahead pages

3.  

4. +#define MAX_READAHEAD   ((512*4096)/PAGE_CACHE_SIZE)

5.  /*

6.   * Given a desired number of PAGE_CACHE_SIZE readahead pages, return a

7.   * sensible upper limit.

8.   */

9.  unsigned long max_sane_readahead(unsigned long nr)

10.  {

11. -       return min(nr, (node_page_state(numa_node_id(), NR_INACTIVE_FILE)

12. -               + node_page_state(numa_node_id(), NR_FREE_PAGES)) / 2);

13. +       return min(nr, MAX_READAHEAD);

14.  }

15.  
16.  

17. commit:600e19afc5f8

18. mm: use only per-device readahead limit

Note: 以上内核代码基于Linux内核主线代码 Linux3.0

标签：node,读取,dd,108,ra,IO,253,128,磁盘
来源： https://blog.csdn.net/yiyeguzhou100/article/details/117826180

本站声明： 1. iCode9 技术分享网（下文简称本站）提供的所有内容，仅供技术学习、探讨和分享；
2. 关于本站的所有留言、评论、转载及引用，纯属内容发起人的个人观点，与本站观点和立场无关；
3. 关于本站的所有言论和文字，纯属内容发起人的个人观点，与本站观点和立场无关；
4. 本站文章均是网友提供，不完全保证技术分享内容的完整性、准确性、时效性、风险性和版权归属；如您发现该文章侵犯了您的权益，可联系我们第一时间进行删除；
5. 本站为非盈利性的个人网站，所有内容不会用来进行牟利，也不会利用任何形式的广告来间接获益，纯粹是为了广大技术爱好者提供技术内容和技术思想的分享性交流网站。