关于ip_conntrack跟踪连接满导致网络丢包问题的分析

我们的线上web服务器在访问量很大时,就会出现网络连接丢包的问题,通过dmesg命令查看日志,发现如下信息:

kernel: ip_conntrack: table full, dropping packet.
kernel: printk: 1 messages suppressed.
kernel: ip_conntrack: table full, dropping packet.
kernel: printk: 2 messages suppressed.
kernel: ip_conntrack: table full, dropping packet.

这里面关键的信息是"ip_conntrack: table full, dropping packet",从这里可以判断出这跟iptables有关系了,因为iptables防火墙使用了ip_conntrack内核模块实现连接跟踪功能,所有的进出数据包都会记录在连接跟踪表中,包括tcp,udp,icmp等,一旦连接跟踪表被填满以后,就会发生丢包,导致网络不稳定。

而我们的服务器确实打开了iptables防火墙,并且都是在网站流量非常高的时候经常会出现这个问题。这个问题的原因是由于web服务器收到了大量的连接,在启用了iptables的情况下,iptables会把所有的连接都做链接跟踪处理,这样iptables就会有一个链接跟踪表,当这个表满的时候,就会出现上面的错误。

iptables的链接跟踪表最大容量配置文件如下:

centos5 netfilter 参数配置文件:

/proc/sys/net/ipv4/netfilter/ip_conntrack_max或者/proc/sys/net/ipv4/ip_conntrack_max

centos6 netfilter 参数配置文件:

/proc/sys/net/netfilter/nf_conntrack_max

由于nf_conntrack 工作在3层,支持IPv4和IPv6,而ip_conntrack只支持IPv4,因此nf_conntrack模块在Linux的2.6.15内核中被引入,而ip_conntrack在Linux的2.6.22内核被移除(centos6.x版本),因此不同版本的系统,配置文件也就不尽相同了。目前大多的ip_conntrack_*已被 nf_conntrack_* 取代,很多ip_conntrack_*仅仅是个软链接,原先的ip_conntrack配置目录/proc/sys/net/ipv4/netfilter/ 仍然存在,但是新的nf_conntrack在/proc/sys/net/netfilter/中,这样做是为了能够向下的兼容。

了解了配置文件的变化后,我们看看这个问题该如何解决,解決方法一般有两个:

1、调整 /proc/ 下面的参数

可以增大适当conntrack 的条目,在CentOS5/RHEL 5下:

(1)运行

sysctl -w net.ipv4.netfilter.ip_conntrack_max=655360

(2).在 /etc/sysctl.conf 中加入:

net.ipv4.netfilter.ip_conntrack_max = 655360

(3).使其生效

sysctl -p

在CentOS 6 /RHEL6下:

(1)运行

sysctl -w net.nf_conntrack_max=100000

(2)在 /etc/sysctl.conf 中加入:

net.nf_conntrack_max = 100000

(3)使其生效

sysctl -p

2、不使用ip_conntrack模块

在CentOS5/RHEL 5下:

不使用ip_conntrack,需要移除state模块,因为使用该模块需要加载ip_conntrack。确保iptables规则中没有出现类似state模块的规则,如果有的话将其移除:

然后注释 /etc/sysconfig/iptables-config 中的:

IPTABLES_MODULES="ip_conntrack_netbios_ns"

最后移除ip_conntrack模块:

[[email protected] ipv4]#  modprobe -r ip_conntrack_netbios_ns xt_state

在CentOS6/RHEL6下:

[[email protected] ipv4]#  modprobe -r nf_conntrack_ipv4 xt_state
[[email protected] ipv4]#  modprobe -r nf_conntrack

现在 /proc/net/ 下面应该没有nf_conntrack了。

两种方法中,第一种简单,但是治标不治本,第二种稍微麻烦,但是毕竟使用,大家可根据情况进行选择。

时间: 2024-09-30 18:36:17

关于ip_conntrack跟踪连接满导致网络丢包问题的分析的相关文章

Linux NAT哈希表满导致服务器丢包

发现ECS Linux服务器出现间歇性丢包的情况,通过tracert.mtr等手段排查,外部网络未见异常. 同时,如下图所示,在系统日志中重复出现大量如下错误信息: Jun 13 15:20:23 web3 kernel: nf_conntrack: table full, dropping packet.Jun 13 15:20:24 web3 kernel: nf_conntrack: table full, dropping packet.Jun 13 15:20:24 web3 kern

[转]nf_conntrack: table full, dropping packet 连接跟踪表已满,开始丢包 的解决办法

nf_conntrack: table full, dropping packet  连接跟踪表已满,开始丢包 的解决办法 中午业务说机器不能登录,我通过USM管理界面登录单板的时候发现机器没有僵死,然后一看日志,g一下子就明白了 tail -2000 /var/log/messages Apr 10 12:48:35 bj-push-pushserver83 kernel: [95129.138804] __ratelimit: 16523 callbacks suppressed (“连接跟

sendto频率过快导致发送丢包

编写一个转发模块,虽然没有要求一转多时要达到多少路(不采用组播的情况下,单纯的一路转成多路),但是本着物尽其用的原则,尽可能测试一下极限. 网络环境:1000M,直连,多网卡 系统:Linux version 3.19.0 接收模式:udp模式的raw socket(优化的话,可以直接通过网卡处理) 发送模式:udp模式的raw socket(优化的话,可以直接通过网卡处理),单线程/多线程 2M               1转N 设备A   ---------------->   转发设备 

网络丢包的四大原因和修复方法

网络链接阻塞数据在网络传输过程中会经过很多设备和网络链接,只要其中一个网络链接在数据到达之前已经满负载了,那么数据将会在这里阻塞一段时间.如果说网络设备非常落后,那么网络链接就没有足够的等待空间给新数据,它唯一能做的就是将信息丢弃. 修复方法:A增加阻塞链接的带宽B使用Qos(流量优先级和资源保留控制机制)优先处理实时应用.尽管这种方法并不能缓解网络链接阻塞情况,但是它可以优先处理语音和视频来降低断线的可能性. 设备性能(路由器.防火墙.交换机)在带宽充足的情况下,如果你的路由器.防火墙.交换机

使用mtr测试网络丢包率和平均延时的脚本实例

mtr(a network diagnostic tool)是一个神奇的指令,能按要求对路由中所有节点进行批量测试.简单敲一个"mtr qq.com"将会有意外收获! 当需要进行产品级的网络测试时,可在服务器上运行一段时间的mtr测试形成报告.如下脚本: #!/bin/bash# 测试网络丢包率和平均延时,注意变量clr和cdt的赋值,不同版本的mtr对应的字段位置不同# 脚本在CentOS 6.2 Linux 2.6.32-220.el6.x86_64 mtr v0.75 上测试通过

FEC(Forward Error Correction)前向纠错 UDP\RTP 中使用用于改善无线等网络丢包等问题--转

FEC(Forward Error Correction)前向纠错 UDP\RTP 中使用用于改善无线等网络丢包等问题 算法暂不介绍. 思路:FEC ENCODE 增加冗余包,当无线等网络丢包之后,接收端使用冗余包可将丢失的包DECODE出来. 举例:10个包,编码后会增加2个包,共12个包发送到接收端,接收端丢失第5和第9包,仅靠剩下的10个包就可以解出第5和第9包. 结果就是,接收端接收到了完整的10个包,代价仅仅是增加了冗余和cpu编解码的消耗. 参考: 1. RTP抗丢包传输方案 点击打

netback的tasklet调度问题及网卡丢包的简单分析

最近在万兆网卡上测试,出现了之前千兆网卡没有出现的一个现象,tasklet版本的netback下,vm进行发包测试,发现vif的interrupt默认绑定在cpu0上,但是vm发包运行时发现host上面cpu1, cpu2的ksoftirqd很高. 从之前的理解上来说,包从netfront出来通过eventchannel notify触发vif的irq处理函数,然后tasklet_schedule调用tx_action,通过一系列处理流程把包发给网卡.所以vif的interrupt绑在哪个cpu

捕获网络数据包并进行分析的开源库-WinPcap

什么是WinPcap WinPcap是一个基于Win32平台的,用于捕获网络数据包并进行分析的开源库. 大多数网络应用程序通过被广泛使用的操作系统元件来访问网络,比如sockets.  这是一种简单的实现方式,因为操作系统 已经妥善处理了底层具体实现细节(比如协议处理,封装数据包等等),并且提供了一个与读写文件类似的,令人熟悉的接口. 然而,有些时候,这种“简单的方式”并不能满足任务的需求,因为有些应用程序需要直接访问网 络中的数据包.也就是说,那些应用程序需要访问原始数据包,即没有被操作系统利

windows RT系统下解决网络丢包问题

windows RT为了保证最高的电池使用时间,电源选项只有节能模式,在节能模式下,无线网卡也处于低功耗状态,导致如果用windows RT系统做网络开发的同仁可能会遇到莫名其妙的丢包现象,要解决此问题,需要将无线网卡调整到高性能模式.但是windows RT系统禁止设置高性能,只能通过其他途径解决. 1.可以在命令行下使用powercfg -setactive 8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c命令将系统设置为高性能模式. 2.方法1可以将网卡设置为高性能