https://www.cnblogs.com/GO-NO-1/p/7324502.html

專案開了個P2P伺服器，但是執行一段時間就會出現丟包問題，具體表現為：
1、udp丟包嚴重（一分鐘收發分別1.5W）

2、ssh（用於運維指令）連線不上該伺服器（超時）

3、伺服器執行好像沒什麼異常，udp假連線數比tcp連線數少（正常應該相近）

首先開始懷疑是不是客戶端有bug，查log發現某段時間有個別客戶端發大量心跳包，開始懷疑這個原因導致服務異常。在多次關服開服後沒出現這個問題，但是伺服器執行一段時間依舊出現上述異常，排除這個原因。

既然不是客戶端導致的。。

就開始在自身找原因，接著懷疑是不是最大連線數、最大檔案開啟數，查了一下伺服器設定：

 ulimit -n　　//可以開啟最大檔案描述符的數量

65536

 

ulimit -a　　//顯示當前所有的 limit 資訊

time(seconds) unlimited
file(blocks) unlimited
data(kbytes) unlimited
stack(kbytes) 8192
coredump(blocks) unlimited
memory(kbytes) unlimited
locked memory(kbytes) 64
process 516037
nofiles 65536
vmemory(kbytes) unlimited
locks unlimited

 

cat /proc/sys/fs/nr_open　　//單程序最大檔案限制

1048576

 

cat /proc/sys/fs/file-max　　//系統最大檔案限制

6605234

再看下伺服器現在相關資訊：

lsof -n　　//檢視伺服器檔案開啟數資訊

 

ps -aef　　//程序資訊

發現無論是檔案描述符開啟數還是檔案開啟數都沒超標---陷入僵局。

覺得應該是系統某個設定不當導致的，但是又無從查起，查 /car/log/messages 裡面的資訊應該能查到點端倪，可是沒許可權。(dmesg  命令好像可以檢視)

後來諮詢其他小組，發現他們也遇到過一樣的問題，問題來自於跟蹤連線表的限制----nf_conntrack/ip_conntrack。

 

 理解nf_conntrack和調整nf_conntrack_max ：nf_conntrack 工作在 3 層，支援 IPv4 和 IPv6，而 ip_conntrack 只支援 IPv4。

 

目前，大多的 ip_conntrack_* 已被 nf_conntrack_* 取代，很多 ip_conntrack_* 僅僅是個 alias，原先的 ip_conntrack 的 /proc/sys/net/ipv4/netfilter/ 依然存在，但是新的 nf_conntrack 在 /proc/sys/net/netfilter/ 中，這個應該是做個向下的相容。

 

nf_conntrack/ip_conntrack 跟 nat 有關，用來跟蹤連線條目，它會使用一個雜湊表來記錄 established 的記錄。nf_conntrack 在 2.6.15 被引入，而 ip_conntrack 在 2.6.22被移除，如果該雜湊表滿了，就會出現問題來。

檢視系統預設跟蹤連線表限制：

cat /proc/sys/net/ipv4/netfilter/ip_conntrack_max 　//最大
cat /proc/sys/net/ipv4/netfilter/ip_conntrack_tcp_timeout_established 　　//儲存時間

 

cat /proc/sys/net/ipv4/netfilter/ip_conntrack_count　　//當前

查看了以後，發現執行一段時間後 跟蹤連線表的確是滿了，導致文章開始所述的情況出現，而 ip_conntrack_max 有個建議值：

CONNTRACK_MAX = RAMSIZE(in bytes)/16384/(ARCH/32)，如32G記憶體可以設定1048576

臨時修改該值：

echo 1048576> /proc/sys/net/ipv4/netfilter/ip_conntrack_max

p2p伺服器重啟後執行恢復正常。