喜迎
元旦
浅析系统调优关于中断调优的处理 | 奋斗的松鼠 - Blog

浅析系统调优关于中断调优的处理

字数统计: 1.7k字   |   阅读时长≈ 7分

关于ceph调优，在调优系统篇已经作了比较全面的介绍，不过，针对其中单独的一些部分，在进行较为深入的调查测试后，其中还是有不少东西值得细说

写在前面

松鼠哥的ceph专业课程上线啦！
面向新手同学，从0实战，全面入门ceph安装部署与运维，有需要的同学赶紧扫码订购吧：

中断对程序的性能影响很大，做好调优对性能提升很大。

关于系统中断

中断，通俗来讲，是程序向系统报告其作业情况的一种方式，作业完成或者遇到问题，自己无法处理而需要系统进行处理的，就需要通过中断的方式通知系统，比如主板插入了某些硬件设备，就会产生一个硬件中断报告给系统，好让系统及时得知该事件；又如程序运行中遇到了致命的段错误，也会通过中断方式通知系统，让系统来进行下一步的处理;值得一提的是，系统收到中断之后，大部分情况下都要停下当前cpu工作，来进行中断的处理，例如网卡收包完成，会产生中断告诉系统，这时系统会安排处理器来处理收到的报文

中断对性能的影响

从上述简单的说明可知，程序会不定时地通过中断方式来向系统报告信息，在某些高性能场合，中断所产生的处理器切换开销是不容忽视的，所以深入了解中断机制，合理进行中断设置安排，对性能的提升是大有裨益的
口说无凭，来点真家伙,下面进行一些网络性能测试来验证一下中断及numa对网络的影响：

1
2
3
4
5
6
7
8
9
10
11
12
[tanweijie@ceph-c204 ~]$ numactl -H
available: 2 nodes (0-1)
node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 12 13 28 29 30 31 32 33 34 35 36 37 38 39 40 41
node 0 size: 64838 MB
node 0 free: 62068 MB
node 1 cpus: 14 15 16 17 18 19 20 21 22 23 24 25 26 27 42 43 44 45 46 47 48 49 50 51 52 53 54 55
node 1 size: 65536 MB
node 1 free: 50786 MB
node distances:
node   0   1
  0:  10  21
  1:  21  10

我的环境中有2个node，每个node有28个cpu，当然，每个node对应一个物理cpu；下面我将所有系统中断处理绑定在node0的最后两个core，也就是40、41上面，然后使用iperf3进行网络性能测试：

1
2
3
4
5
6
7
8
9
[tanweijie@ceph-c204 ~]$ cat chang_interupt.sh
#!/bin/bash

procs=`ls -l /proc/irq/ |grep -v 'default'|wc -l`
for k in $( seq 0 $procs )
do
    sudo echo 000300,00000000 > /proc/irq/$k/smp_affinity
    #cat /proc/irq/$k/smp_affinity
done

执行上述脚本后，即可完成绑定，它主要是通过修改中断的cpu掩码来修改处理中断的cpu；接下来我们使用numactl来跑iperf3，然后使用另外一个设备来充当客户端进行网络测试，这里使用39号cpu测试，是因为39号cpu和40、41号cpu在相同的物理cpu上，这样中断处理就不会跨node，稍后将会进行跨node的比较，此环境使用的是40Gbps的IB卡及一个4036E IB交换机

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
[tanweijie@ceph-c204 ~]$ /usr/bin/numactl -a -C 39 -m 0 /usr/bin/iperf3 -s
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
在另外一台设备启动客户端进行测试
[tanweijie@client-c220 ~]$ iperf3 -c 172.25.59.204 -i1 -t 60
Connecting to host 172.25.59.204, port 5201
[  4] local 172.25.59.220 port 50866 connected to 172.25.59.204 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec  2.74 GBytes  23.5 Gbits/sec    0   5.99 MBytes
[  4]   1.00-2.00   sec  2.74 GBytes  23.5 Gbits/sec    0   5.99 MBytes
[  4]   2.00-3.00   sec  2.74 GBytes  23.5 Gbits/sec    0   5.99 MBytes
[  4]   3.00-4.00   sec  2.74 GBytes  23.5 Gbits/sec    0   5.99 MBytes
[  4]   4.00-5.00   sec  2.73 GBytes  23.5 Gbits/sec    0   5.99 MBytes
[  4]   5.00-6.00   sec  2.73 GBytes  23.5 Gbits/sec    0   5.99 MBytes
[  4]   6.00-7.00   sec  2.74 GBytes  23.5 Gbits/sec    0   5.99 MBytes
[  4]   7.00-8.00   sec  2.73 GBytes  23.5 Gbits/sec    0   5.99 MBytes

可以看到，网络带宽23.5 Gbits/sec非常稳定，结果也是23.5 Gbits/sec，这时我们使用另外一个node的cpu来启动测试，进行对比，client没有作任何的修改

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
[tanweijie@ceph-c204 ~]$ /usr/bin/numactl -a -C 49 -m 0 /usr/bin/iperf3 -s
-----------------------------------------------------------
Server listening on 5201
-----------------------------------------------------------
再次启动相同的客户端进行测试
[tanweijie@client-c220 ~]$ iperf3 -c 172.25.59.204 -i1 -t 60
Connecting to host 172.25.59.204, port 5201
[  4] local 172.25.59.220 port 50904 connected to 172.25.59.204 port 5201
[ ID] Interval           Transfer     Bandwidth       Retr  Cwnd
[  4]   0.00-1.00   sec  2.22 GBytes  19.1 Gbits/sec    0   2.56 MBytes
[  4]   1.00-2.00   sec  2.21 GBytes  19.0 Gbits/sec    0   2.56 MBytes
[  4]   2.00-3.00   sec  2.24 GBytes  19.3 Gbits/sec    0   2.56 MBytes
[  4]   3.00-4.00   sec  2.31 GBytes  19.9 Gbits/sec    0   2.56 MBytes
[  4]   4.00-5.00   sec  2.32 GBytes  20.0 Gbits/sec    0   2.56 MBytes
[  4]   5.00-6.00   sec  2.26 GBytes  19.4 Gbits/sec    0   2.56 MBytes
[  4]   6.00-7.00   sec  2.19 GBytes  18.8 Gbits/sec    0   2.56 MBytes

测试结果相比此前有比较明显的性能下降，并且有波动，我们这里仅仅只是使用不同的node的cpu进行server的启动，就产生了明显的差别，这里进行一下分析：

node与内存的影响分析

此前的系统调优篇也介绍过，不同的node进行内存访问和数据交换需要付出的代价是很大的，这里，我们使用了iperf3绑定在node1上，中断则绑定在node0的最后两个cpu上面，当网络数据进行交互时，大流量产生了非常多的中断请求(可以使用cat /proc/interrupts |grep mlx4查看)，使得系统被频繁干扰，负责处理中断的是相同的物理cpu的时候，其数据传递所需要的代价小得多，另外一点值得关注，就是负责通信的IB网卡是默认绑定到node0的，这就意味着，IB卡收到数据包之后，首先会存放在node0的local内存，再通知cpu进行处理，而处理中断的cpu如果在node0，则不需要进行跨node传递，其效率提升就会比较明显

对ceph调优的启示

对ceph的系统优化，当前我们的做法就是，每个osd绑定2个core，rgw绑定14个core，保持node对齐，并且将IB网卡中断绑定到osd对应的node的cpu上，其余中断则全部绑定到系统使用的node上面，实际测试发现，对集群网络稳定性和网络效率有显著的提升

赏

谢谢你请我吃糖果

支付宝
微信
  • 本文作者： 奋斗的松鼠
  • 本文链接： http://www.strugglesquirrel.com/2018/04/22/浅析系统调优关于中断调优的处理/
  • 版权声明： 本博客所有文章除特别声明外，创作版权均为作者个人所有，未经允许禁止转载！

扫一扫，分享到微信

tag:

    缺失模块。
    1、请确保node版本大于6.2
    2、在博客根目录（注意不是yilia-plus根目录）执行以下命令：
    npm i hexo-generator-json-content --save

    3、在根目录_config.yml里添加配置： 

      jsonContent:
    meta: false
    pages: false
    posts:
      title: true
      date: true
      path: true
      text: false
      raw: false
      content: false
      slug: false
      updated: false
      comments: false
      link: false
      permalink: false
      excerpt: false
      categories: false
      tags: true

松鼠哥，存储研发专家
曾就职于深信服北京研发中心，负责存储相关产品的调研测试
在分布式存储领域深耕近十年，实战经验和理论经验功力深厚
累计管理及上线生产集群超过600个，机器超3万台，磁盘总数超过80万块，总容量达到EB级别。