故障排查：
昨天下午開始，網站反映很慢，常常發生502，肯定有問題，
趕緊登錄服務器進行排查。首先使用ping 內網IP的方式查看內網的連通性，ping的過程中出現丟包現象，信息如下:
64 bytes from 10.1.1.1: icmp_seq=34 ttl=255 time=0.928 ms
64 bytes from 10.1.1.1: icmp_seq=35 ttl=255 time=1.01 ms
ping: sendmsg: Operation not permitted
ping: sendmsg: Operation not permitted
顯示ping不被允許，奇怪，防火牆上明明開通了icmp的協議。有問題先看日誌，日誌文件一般會有所記錄，tail –f /var/log/messages，發現大量的如下內容：
Sep 13 09:11:21 dowload_server1 kernel: printk: 261 messagessuppressed.
Sep 13 09:11:21 dowload_server1 kernel: ip_conntrack: table full,dropping packet
發現是當前會話數已經滿了，因此出現丟包現象。這裏對ip_conntrack做一下簡單的介紹：IP_conntrack表示連接跟蹤數據庫(conntrack database)，代表NAT機器跟蹤連接的數目，連接跟蹤表能容納多少記錄是被一個變量控制的，它可由內核中的ip-sysctl函數設置。每一個跟蹤連接表會佔用350字節的內核存儲空間，時間一長就會把默認的空間填滿，那麼默認空間是多少？在內存爲64MB的機器上是4096,內存爲128MB是8192,內存爲256MB是16384
通過如下命令查看當前的會話數：
cat /proc/net/ip_conntrack | wc –l
或者使用：
cat /proc/sys/net/ipv4/netfilter/ip_conntrack_count
使用如下命令查看設置的最大會話數
cat /proc/sys/net/ipv4/ip_conntrack_max
解決辦法：
發現確實已經達到了最大會話數，通過google發現，可以直接調大用戶的最大會話數，命令爲：
echo "102400" > /proc/sys/net/ipv4/ip_conntrack_max
執行此命令後，不在丟包了，ping也正常了。但是這樣設置不會永久保存，當系統重啓後設置會丟失，因此需要保存到/etc/sysctl.conf，在/etc/sysctl.conf中加入：net.ipv4.ip_conntrack_max =102400，然後執行/sbin/sysctl –p刷新內核參數即可，如果出現error:"net.ipv4.ip_conntract_max" is an unknown key報錯的話，需要加載ip_conntract模塊，使用modprobe ip_conntrack加載，使用lsmod | grepip_conntrack查看模塊是否加載。
終極解決：
爲了使徹底解決此問題，還需要再設置一個東西，那就是會話連接超時變量，這個參數設置太長的話就會導致會話連接數不斷增加，默認是設置爲432000秒，很顯然這個值太大了，通過如下命令設置小一點：
echo 21600>/proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established
設置成21600也就是6小時，這樣會自動清除6小時候後的無效鏈接。記得將這句話加到自動啓動文件/etc/rc.local文件中去。
故障總結：
此次故障顯示我們必須加強服務器的監控，這樣才能第一時間獲取故障問題並在第一時間解決，減少此類問題給公司造成損失。另外出現問題多看日誌，日誌往往能看出問題的蛛絲馬跡，通過日誌我們能更快地定位問題，從而找到問題的解決辦法。