Phenomenon: Suddenly found that access to the site is slow, the server's CPU, memory and disk usage are normal analysis process and solution: query/var/log/message log found that there is such a record "Ip_conntrack table full dropping packet". Kernel uses the Ip_conntrack module to record the status of the Iptables network packet, and save it to the table (this table in memory), if the network is busy, such as high connection, high concurrent connection, etc. will lead to the gradual use of this table free space, usually this tab Le is very big not easy to fill and can clean up itself, table records will stay in the table to occupy space until the source IP to send a RST packet, but if there is an attack, the wrong network configuration, the problem of the routing/router, the problem of the NIC, etc., will cause the source IP to send this RST The package does not receive, so accumulate in the table, the more accumulated until the full, full after the iptables will drop packets, there is no external connection to the server situation. Solution: Iptables starts with the current buckets and Conntrack_max values in the log and how much memory each trace connection consumes: that is, 304MB memory will support 1,048,576 trace connection records, Therefore, the appropriate values need to be configured according to the server's memory size. Permanently modify
Ip_conntrack_max and hashsize1) Increase Ip_conntrack_max (set to 2^20, default is 2^16=65536) # vi/etc/ Sysctl.confnet.ipv4.ip_conntrack_max = 10485762) Increase hashsize (on i386 architecture, hashsize = CONNTRACK_MAX/8) # vi/etc/modprobe.co Nfoptions Ip_conntrack hashsize=131072 Then restart the iptables service, you can see that the parameters are in effect in messages: # service Iptables restart
Iptables's Conntrack is full, which leads to slow access to the site.
