一次故障排查经过

早上例行巡检的时候发现后台签到数只有5000多，前几天每天早上都有8000多的，咋一下就变5000多了呢？然后就开始了漫长的排查过程。

首先想到的是dns解析的问题。因为后台有大量的签到数，说明网站是正常的。能够一下子掉几千的签到数，有可能是某地区的DNS服务器解析出问题，抱着怀疑的态度在DNSPOD上对签到服务器的域名进行了解析诊断。诊断结果为47个DNS解析正常。

排除了dns的解析问题后，就想着是不是服务器这边出了问题呢。于是登录上nginx服务器，对当前的日志进行统计(cat /usr/local/nginx/logs/host.access.log|grep signin|cut -d ' ' -f 10 |sort|uniq -c)，统计结果为除了状态码200有17218个，状态码499有331，然后就没有其它的结果了。这时候客服这正好有一台不能正常签到，就在web上用MiniSniffer对IP和端口进行过滤后抓包，抓包结果为空，啥也没有，而且nginx的日志里也没有这台设备。于是又以网页形式进行了访问，发现一切正常，而且日志也有记录正常。

这时候领导说服务器的80端口在telnet时会偶尔出现无法连接的状态，怀疑是机房网络有问题。于是联系了机房进行排查，这边在nginx服务器做ping包测试其延迟，发现ping腾讯QQ延迟基本在39到40以内。但偶尔会出现ping: sendmsg: Operation not permitted状态。且使用命令（netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'）命令进行排查时，发现FIN_WAIT在某一瞬时有700左右。于是百度之。

后百度到文章(http://blog.chinaunix.net/space.php?uid=346158&do=blog&id=2130887)，说是因为linux系统中默认存在一个IP_conntrack连接跟踪数据库(conntrack database)，代表NAT机器跟踪连接的数目，连接跟踪表能容纳多少记录是被一个变量控制的，它可由内核中的ip- sysctl函数设置。每一个跟踪连接表会占用350字节的内核存储空间，时间一长就会把默认的空间填满，默认在内存为64MB的机器上是4096,内存为128MB是 8192。ip_conntrack_tcp_timeout_established这个参数是连接超时，默认超时时间是5天，表示在5天后清除掉无效的连接，这样过几天就出现iptables full是说hash表已经被占满了，里面包括许多超时的连接，这其中基本100%已经是无效的了。

最后确认在/etc/sysctl.conf文件里没有添加上述设置，于是在它最下面添加下面两行：

net.ipv4.ip_conntrack_max = 655360 
net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 180 
 
使配置立即生效： 
/sbin/sysctl -p 
net.ipv4.ip_conntrack_max = 655360

net.ipv4.netfilter.ip_conntrack_tcp_timeout_established = 180

然后执行/sbin/sysctl -p让它立即生效后，发现后台签到数瞬间回到了8000多。ping腾讯扣扣也没有出现sendmsg: Operation not permitted类错误信息。