由ip_conntrack跟蹤連接庫滿導致的大量丟包現象

剛上線不久的一臺服務器,晚上高峯時有很多客戶反映連不上服務器,通過在本地測試發現有的連接可以連上但有的不行,趕緊連上服務器查看日誌,發現大量如下錯誤… 

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 立即生效

補充:

        查看內核現在連接數量
        cat /proc/sys/net/ipv4/netfilter/ip_conntrack_count 
        查看內核net.ipv4.ip_conntrack_max和net.ipv4.netfilter.ip_conntrack_max的值
        sysctl -a|grep -e “ip_conntrack_max”

附:s135的優化方案:

net.ipv4.tcp_max_syn_backlog = 65536
net.core.netdev_max_backlog =  32768
net.core.somaxconn = 32768

net.core.wmem_default = 8388608
net.core.rmem_default = 8388608
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216

net.ipv4.tcp_timestamps = 0
net.ipv4.tcp_synack_retries = 2
net.ipv4.tcp_syn_retries = 2

net.ipv4.tcp_tw_recycle = 1
#net.ipv4.tcp_tw_len = 1
net.ipv4.tcp_tw_reuse = 1

net.ipv4.tcp_mem = 94500000 915000000 927000000
net.ipv4.tcp_max_orphans = 3276800

#net.ipv4.tcp_fin_timeout = 30
#net.ipv4.tcp_keepalive_time = 120
net.ipv4.ip_local_port_range = 1024  65535

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章