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 unlimitedcat /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服务器重启后运行恢复正常。