对该参数的理解
所以我们看到的现象就是，内核收到了新的syn报文，但只是默默drop了(没什么好处理方法，回RST可能误伤)，所以造成了psql连接超时。
举例说明问题
只要新包的时戳比上次看到的时戳小，就判断报文有问题。可见，同一个peer的时戳，必须要线性增长，否则判断会出错。显然，一般情况下对于同一个客户端，”时戳线性增长”这个前提是满足的，但如果客户端在NAT之后呢？
如果192.168.1.100在频繁的连接建立、断开，192.168.1.101可能很久都无法连接的上。
转载自
一，故障描述：
从昨天开始，在值班群中陆续值班人员反映系统后台存在卡顿问题，如下图：
而且在卡顿的同时登陆服务器也会卡好久。此现象只在一台服务器有出现。
二，故障分析：
为什么会连接失败呢？
5，使用tcpdump抓包在卡顿的时候会抓到大量的syn请求，但服务器没有响应：
6，登录服务器查看tcp相关数据
$ netstat -s | grep -i listen
326 times the listen queue of a socket overflowed 751346 SYNs to LISTEN sockets dropped发现在卡顿时有大量tcp syn包被丢弃，数值一直在增长。
三，故障处理：
在查阅资料并结合实际情况后，发现该服务器同时启用了 tcp_timestamps和tcp_tw_recycle参数。
后想起，之前同事为改善time_wait连接数过多问题曾改过该内核参数。
解决办法是，关闭tcp_tw_recycle：
$ vi /etc/sysctl.conf
#修改为如下
net.ipv4.tcp_tw_recycle = 0
#保存退出，使之生效 $ sysctl -p再观察，发现服务已正常，卡顿现象消失。
四，总结：
我们先来man一下这两个参数(man tcp)：
tcp_timestamps (Boolean; default: enabled; since Linux 2.2)
Enable RFC 1323 TCP timestamps.tcp_timestamp 是 RFC1323 定义的优化选项，主要用于 TCP 连接中 RTT(Round Trip Time) 的计算，开启 tcp_timestamp 有利于系统计算更加准确的 RTT，也就有利于 TCP 性能的提升。（默认开启）
关于tcp_timestamps详情请见：
tcp_tw_recycle (Boolean; default: disabled; since Linux 2.4)
Enable fast recycling of TIME_WAIT sockets. Enabling this option is not recommended since this causes problems when working with NAT (Network Address Translation).开启tcp_tw_recycle会启用tcp time_wait的快速回收，这个参数不建议在NAT环境中启用，它会引起相关问题。
主机A SIP:P1 (时间戳T0) ---> Server 主机A断开后
主机B SIP:P1 (时间戳T2) T2 < T0 ---> Server 丢弃
经过此次故障，告诫我们在处理线上问题时，不能盲目修改参数，一定要经过测试，确认无误后，再应用于生产环境。同时，也要加深对相关内核参数的认识和理解。