网络不稳定,会导致某些核的软中断很高么?那么,下面我们来分析下这个论断的准确性。

环境描述:

网卡软中断进行了绑核。设备具备80个核,960个网卡中断,没开启bbr,全部是tcp呼叫。

# cat /proc/cpuinfo |grep processor|wc -l
# cat /proc/interrupts |grep   eth |wc -l
# cat /proc/irq//smp_affinity
,,,,,,

每个网卡中断指定在一个cpu核上。

问题描述:发现有的核上软中断比其他核高很多,因为当时看到有大概2个点的重传率。

分析过程:

首先,重传的报文数量,确实有可能会引起软中断增高,那我们来看下具体怎么影响的。

tcp_v4_init_sock---->tcp_init_sock---->tcp_init_xmit_timers---->inet_csk_init_xmit_timers

void inet_csk_init_xmit_timers(struct sock *sk,
void (*retransmit_handler)(unsigned long),
void (*delack_handler)(unsigned long),
void (*keepalive_handler)(unsigned long))
{
struct inet_connection_sock *icsk = inet_csk(sk); setup_timer(&icsk->icsk_retransmit_timer, retransmit_handler,
(unsigned long)sk);
setup_timer(&icsk->icsk_delack_timer, delack_handler,
(unsigned long)sk);
setup_timer(&sk->sk_timer, keepalive_handler, (unsigned long)sk);
icsk->icsk_pending = icsk->icsk_ack.pending = ;
}

我们看到,在这个地方设置了重传定时器icsk_retransmit_timer,根据软中断的数组:

enum
{
HI_SOFTIRQ=,
TIMER_SOFTIRQ,
NET_TX_SOFTIRQ,
NET_RX_SOFTIRQ,
BLOCK_SOFTIRQ,
BLOCK_IOPOLL_SOFTIRQ,
TASKLET_SOFTIRQ,
SCHED_SOFTIRQ,
HRTIMER_SOFTIRQ, /* Unused, but kept as tools rely on the
numbering. Sigh! */
RCU_SOFTIRQ, /* Preferable RCU should always be the last softirq */ NR_SOFTIRQS
};

我们的timer,是利用TIMER_SOFTIRQ 这个中断号,那么根据中断号在cpu上分布是否均匀,就能看出影响多大。

 LOC:                                                                                                                                                                 Local timer interrupts

除了cpu0,其他核都是很均匀了。

事实上,这个问题直接分析/proc/interrupts就能看出来,其实是由于某些核上的NET_TX_SOFTIRQ非常少导致的。

那么问题来了,虽然我们知道了重传的报文对cpu的软中断数不均衡情况影响很小,那为什么呼叫的时候,各个cpu的软中断数相差很大呢。

回到问题的本质,我们的系统其实开启了RPS和RFS,

#  cat /sys/class/net/eth10/queues/rx-/rps_cpus
,,,,,,,,,,,0000ffff,ffffffff,ffffffff

# cat /sys/class/net/eth10/queues/rx-0/rps_flow_cnt
4096

RPS(Receive Packet Steering)主要是把软中断的负载均衡到各个cpu,简单来说,是网卡驱动对每个流生成一个hash标识,这个HASH值得计算可以通过四元组来计算(SIP,SPORT,DIP,DPORT)。看起来好像没问题,

其实问题就在于,我们是多媒体服务器,用于测试的机器的ip并没有篡改,我们的源ip和目的ip都是固定的,目的端口在第一次请求建联的时候也是固定的,后续的发流也就是靠源端口和目的端口来保证hash的散列性,通过抓包发现,其实这个散列性并不好。当我们把源ip配置很多的时候,现象得到了很大的改善,把服务器的目的ip多增加一些的时候,效果也更好。

进一步地,除了用肉眼观察,我怎么确定我们的软中断处理情况呢?答案是perf。

比如我要查看cpu14的软中断处理情况,

[root@host]# perf top -C  -e  irq:softirq_entry

Samples: 290K of event 'irq:softirq_entry', Event count (approx.):
Overhead Trace output
92.30% vec= [action=NET_RX]
3.24% vec= [action=HI]
2.83% vec= [action=TIMER]
1.09% vec= [action=RCU]
0.49% vec= [action=SCHED]
0.05% vec= [action=NET_TX]

可以明显看出,收包是中断的大头,然后看哪个中断号占其中的大头呢?可以很明显看到irq为1355的就占了绝大多数。

perf top -C  -e  irq:irq_handler_entry
90.10% irq= name=i40e-eth7-TxRx-
9.06% irq= name=i40e-eth2-TxRx-

所以说,虽然中断绑核了,但不一定就中断均匀,因为某个中断号触发次数可能就别的中断号高很多。

这么说,如果中断数量差不多,是不是si%就应该差不多呢,理论上是如此,理论上的意思就是:cpu处理该中断的时间消耗差不多,因为top里面看的是时间占比,

比如同样处理一个中断,不同的cpu核的频率不一样的话,也会造成处理软中断最终的时间占比不一样。这种情况比较罕见,需要使用如下命令进行确认:

# cpupower -c  frequency-info
analyzing CPU :
driver: intel_pstate
CPUs which run at the same hardware frequency:
CPUs which need to have their frequency coordinated by software:
maximum transition latency: Cannot determine or is not supported.
hardware limits: MHz - 2.70 GHz
available cpufreq governors: performance powersave
current policy: frequency should be within MHz and 2.70 GHz.
The governor "performance" may decide which speed to use
within this range.
current CPU frequency: 2.70 GHz (asserted by call to hardware)
boost state support:
Supported: yes
Active: yes

linux tcp重传多会导致软中断在各个核很不均匀么?的更多相关文章

  1. 对TCP重传的进一步认识

    http://blog.sina.com.cn/s/blog_4d276ac901011ee7.html ——TCM项目所得 一.看图说话 1.基于套接字的TCP服务器/客户端程序流程 2.TCP三次 ...

  2. Linux TCP/IP调优-Linux内核参数注释

    固定文件的内核参数 下列文件所在目录: /proc/sys/net/ipv4/ 名称 默认值 建议值 描述 tcpsyn_retries 5 1 对于一个新建连接,内核要发送多少个SYN连接请求才决定 ...

  3. 一站式学习Wireshark(四):网络性能排查之TCP重传与重复ACK

    作为网络管理员,很多时间必然会耗费在修复慢速服务器和其他终端.但用户感到网络运行缓慢并不意味着就是网络问题. 解决网络性能问题,首先从TCP错误恢复功能(TCP重传与重复ACK)和流控功能说起.之后阐 ...

  4. LINUX TCP套接字详细配置

    提高服务器的负载能力,是一个永恒的话题.在一台服务器CPU和内存资源额定有限的情况下,最大的压榨服务器的性能,是最终的目的.要提高 Linux系统下的负载能力,可以先启用Apache的Worker模式 ...

  5. Linux TCP协议使用的变量

    Linux /proc/sys/net/ipv4/* 变量 TCP变量:somaxconn - INTEGER    listen()的backlog参数的上限,在用户态为SOMAXCONN.默认是1 ...

  6. [转]linux tcp/ip调优

    LINUX tcp/ip性能调优 On 2011年03月15日, in linux, tips, by netoearth 在TCP/IP协议中,TCP协议提供可靠的连接服务,采用三次握手建立一个连接 ...

  7. 【图解】你还在为 TCP 重传、滑动窗口、流量控制、拥塞控制发愁吗?看完图解就不愁了

    每日一句英语学习,每天进步一点点: 前言 前一篇「硬不硬你说了算!近 40 张图解被问千百遍的 TCP 三次握手和四次挥手面试题」得到了很多读者的认可,在此特别感谢你们的认可,大家都暖暖的. 来了,今 ...

  8. Wireshark(四):网络性能排查之TCP重传与重复ACK

    原文出处: EMC中文支持论坛 作为网络管理员,很多时间必然会耗费在修复慢速服务器和其他终端.但用户感到网络运行缓慢并不意味着就是网络问题. 解决网络性能问题,首先从TCP错误恢复功能(TCP重传与重 ...

  9. TCP重传问题解决思路

    处理线上问题经常会碰到网络抖动的情况, 网络抖动有可能就是TCP重传导致,下面简单说下TCP重传的排查思路,不一定能完全解决问题 1. 找运维同事确定是否是网线问题, 如果是网线问题请更换网线 2. ...

随机推荐

  1. 一句话理解字符编码(Unicode ,UTF8,UTF16)

    Unicode和ASCII码属于同一级别的,都是字符集,字符集规定从1到这个字符集的最大范围每个序号都各表示什么意思.比如ASCII字符集中序号65表示"A". 那接下来的UTF8 ...

  2. DeepLearning.ai学习笔记(四)卷积神经网络 -- week3 目标检测

    一.目标定位 这一小节视频主要介绍了我们在实现目标定位时标签该如何定义. 上图左下角给出了损失函数的计算公式(这里使用的是平方差) 如图示,加入我们需要定位出图像中是否有pedestrian,car, ...

  3. Java string和各种格式互转 string转int int转string

    Java string和各种格式互转 string转int int转string 简单收集记录下 其他类型转String String s = String.valueOf( value); // 其 ...

  4. div 初始高度,并随内容高度变化

    前几天做个邮箱系统,其中在内容的div设置了高度为200px; 可是在内容大于200高度后就出现了内容的溢出. 如图: 查完资料够才知道css有个min-height; 设置div的初始化高度,设置属 ...

  5. CTF---Web入门第四题 Forms

    Forms分值:10 来源: Ph0enix 难度:易 参与人数:4945人 Get Flag:2776人 答题人数:2824人 解题通过率:98% 似乎有人觉得PIN码是不可破解的,让我们证明他是错 ...

  6. BZOJ 3668: [Noi2014]起床困难综合症【贪心】

    3668: [Noi2014]起床困难综合症 Time Limit: 10 Sec  Memory Limit: 512 MBSubmit: 2326  Solved: 1305[Submit][St ...

  7. 2017 Multi-University Training Contest - Team 9 1005&&HDU 6165 FFF at Valentine【强联通缩点+拓扑排序】

    FFF at Valentine Time Limit: 6000/3000 MS (Java/Others)    Memory Limit: 65536/65536 K (Java/Others) ...

  8. HDU 2037 今年暑假不AC(贪心,区间更新,板子题)

    今年暑假不AC Time Limit: 2000/1000 MS (Java/Others)    Memory Limit: 65536/32768 K (Java/Others) Total Su ...

  9. hdu_2604Queuing(快速幂矩阵)

    题目链接:http://acm.hdu.edu.cn/showproblem.php?pid=2604 Queuing Time Limit: 10000/5000 MS (Java/Others)  ...

  10. HDU--2018

    母牛的故事 Time Limit: 2000/1000 MS (Java/Others)    Memory Limit: 65536/32768 K (Java/Others) Total Subm ...