系统端口也是稀缺资源呐
直面问题
上午的时候，公司的一个网站因为激发流量，服务有些不稳定。通过一个监控页面显示memcached已经无法连接，但是memcached进程明明是存活的。于是好奇的telnet了一下，果然有些问题，给我反馈了一个Cannot assign requested address。然而当时也没有多想，单纯的以为端口不通了，索性就重启了memcached，可是发现并没有解决问题。而且看到端口也是在监听状态，并且用本机IP的连接11211端口是可以连通的。
在思考了一会儿之后，看了一下memcached的tcp状态，发现已经积攒了数万的TIME_WAIT。这下子就能对的上先前的“无法分配响应地址”的错误提示了。结合这个网站的实际环境，因为程序本身强依赖memcached，而且该服务器的session也存放在本地的memcached。所以可能由于访问量突然的激增，导致memcached并发了太多的短连接，并且这些结束的连接需要2MSL（Max Segment Lifetime）才会变成CLOSED状态。如此反复就超过Linux本身的限制了。
既然发现了问题，那就先临时处理掉这些TIME_WAIT的连接吧。先后往内核里塞了net.ipv4.tcp_tw_reuse = 1和net.ipv4.tcp_tw_recycle = 1，并且在端口都回收之后，禁用了net.ipv4.tcp_tw_recycle。不过要是想有效的解决这个问题，最好还是程序端连接memcached的时候，改成长连接。然而已经没人维护的项目，也就想想而已啦。
虽然之前看文章，也看到过说排障的时候注意TIME_WAIT，然而在实际场景的时候仍然没有相关的意识。然后又想起之前的几次线上应急处理，如果查看了系统TCP连接状态的话，可能会有更多的发现，但是因为没有意识，也许就错过了。看样子，得考虑在zabbix里面添加相关程序的tcp状态收集了。
今天就先草草记录一下吧，多敲打敲打自己。