刚上线不久的一台服务器，晚上高峰时有很多客户反映连不上服务器，通过在本地测试发现有的连接可以连上但有的不行，赶紧连上服务器查看日志，发现大量如下错误...
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.
kernel: printk: 1 messages suppressed.
ip_conntrack 这个东西是连接跟踪数据库(conntrack database)，代表NAT机器跟踪连接的数目（不过只要打开iptables就会开始跟踪）如果这个东西满了结果可想而知
赶紧查看当前的值发现很快就能到2万多
wc -l /proc/net/ip_conntrack
23722 /proc/net/ip_conntrack
看看最大值限制
cat /proc/sys/net/ipv4/netfilter/ip_conntrack_max
65536
访问稍大一点就会突破这个值
保留时间是多久？
cat /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established
432000
默认是5天，没必要这么久
先临时调大看看效果
echo 655350 > /proc/sys/net/ipv4/netfilter/ip_conntrack_max
echo 10800 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established
改完后观察了一段时间，发现服务器连接正常，没有再发生类似情况
修改/etc/sysctl.conf
net.ipv4.netfilter.ip_conntrack_max = 655360
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 10800
sysctl -p 立即生效
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.
kernel: printk: 1 messages suppressed.
ip_conntrack 这个东西是连接跟踪数据库(conntrack database)，代表NAT机器跟踪连接的数目（不过只要打开iptables就会开始跟踪）如果这个东西满了结果可想而知
赶紧查看当前的值发现很快就能到2万多
wc -l /proc/net/ip_conntrack
23722 /proc/net/ip_conntrack
看看最大值限制
cat /proc/sys/net/ipv4/netfilter/ip_conntrack_max
65536
访问稍大一点就会突破这个值
保留时间是多久？
cat /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established
432000
默认是5天，没必要这么久
先临时调大看看效果
echo 655350 > /proc/sys/net/ipv4/netfilter/ip_conntrack_max
echo 10800 > /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established
改完后观察了一段时间，发现服务器连接正常，没有再发生类似情况
修改/etc/sysctl.conf
net.ipv4.netfilter.ip_conntrack_max = 655360
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 10800
sysctl -p 立即生效
OK问题排除，在上线前没有估计好服务器的访问量，从而忽略了对一些内核参数的修改。这点需要我以后多注意。
本文转自 geekwolf 51CTO博客，原文链接:http://blog.51cto.com/linuxgeek/998983
