在下午1点左右 业务高峰期，突然收到警报网站无法访问，直接打开网站，发现所有请求都超时了，没有回音。
查看数据库，CPU负载10左右徘徊，服务器CPU也是在20左右徘徊。
推测是服务器的网络出现问题。

使用 netstat -n | awk '/^tcp/ {++S[$NF]} END {for(a in S) print a, S[a]}'查看TCP的连接情况，发现了大量的CLOSED_WAIT连接以及大量的TIME_WAIT。遂推测是大量的连接占用完了所有的可用的连接，导致请求一直在排队却一直得不到处理，同时服务器又收不到请求操作。

重启，5分钟后问题依旧。

遂优化，首先是后台查找问题，是否有太多请求耗时过长，导致被中断。
linux内核tcp参数优化。

tcp调优 - tcp_fin_timeout

首先是调整tcp_fin_timeout参数，防止出现过多的CLOSED_WAIT，查看默认设置，在/etc/sysctl.conf文件内或者是在/proc/sys/net/ipv4/tcp_fin_timeout 文件内。
cat /proc/sys/net/ipv4/tcp_fin_timeout查看设置值为60
echo 20 > /proc/sys/net/ipv4/tcp_fin_timeout 修改为20
再次 cat /proc/sys/net/ipv4/tcp_fin_timeout查看设置值已经更改为20。

tcp调优 - tcp_tw_reuse

tcp_tw_reuse是将time_wait的连接，重新用于新的连接，减少浪费。
cat /proc/sys/net/ipv4/tcp_tw_reuse查看默认值为0，即关闭。
echo 1 > /proc/sys/net/ipv4/tcp_tw_reuse 设置为打开
再次 cat /proc/sys/net/ipv4/tcp_tw_reuse查看设置值已经更改为1。

tcp调优 - tcp_max_tw_buckets

tcp_max_tw_buckets是设置time_wait的最大数量，默认值为5000，查资料最大可以到26W多，另一篇文章是写的55000，综合考虑，我改成了45000，这样也是原来的9倍了。
vim /etc/sysctl.comf

修改max time wait buckets

sysctl -p或 /sbin/sysctl -p使修改生效

等我找到问题并修改好的时候，业务高峰期已经过了。

等待下一次的验证。

验证结果

失败，很失败。又去排查了一遍代码，原来是定位api请求没有限制超时时间，导致api服务器一直没有返回信息，服务端被吊死。

新一轮的问题

今天又遇到了这个问题，但是是有非常多的time_wait而不是close_wait。按照上面的方法改过了之后，发现网站依然很卡（一个请求的响应时间从0.2s不到，一直到了5-10s，甚至直接超时）
最后经过重重排查，成功定位问题，Redis的带宽达到了最高值(10MB/S)，临时带宽升级，发现网站访问速度有所改善。
redis，主要存放的是用户的token和常用个人信息，由于用户高峰期，请求非常密集，导致对于token的存取量巨大，从而达到了带宽限制。
解决这个也容易，直接氪金，升级读写分离版本，带宽限制高达192MB/S。访问迅速正常后，过了几分钟，经过了30秒的熔断后，网站彻底恢复，正常使用。