linux 服务器丢包故障排查

项目开了个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服务器重启后运行恢复正常。

---

参考引用：

http://itoedr.blog.163.com/blog/static/120284297201451013130868/

http://www.cnblogs.com/276815076/p/5736272.html

http://www.sdnlab.com/17530.html