最近生产环境频繁报出too many open files，导致系统无法对外提供服务。
该系统采用golang开发，但是并发量并不大，而是一个小型的内部管理系统，按理说默认的1024的文件句柄数是完全够用的，本来团队人员有提出增加文件句柄数来解决问题。我的想法是1024对于小型的没什么并发量的系统是完全够用的，不需要增加句柄数来解决问题，而且增加了只是治标不治本，必须找到根源才可以。
于是我们开始定位问题，查找的思路是第一步确定系统中是否有http请求链接是否存在没有主动关闭的链接，于是针对调用外部的http的地方进行了排查和测试，结果都是正常的，说明本身自己的代码是没有问题的；第二步查询服务器上的tcp状态，发现有大概几百的time_wait的状态，但是time_wait的状态属于服务器主动断开才会出现的，说明服务器确实有很多连接，但是几百的time_wait也不会导致too many open files的问题。于是进一步分析established的信息，发现有大量的连接，而且分析下来发现客户端IP地址都是来源于三个固定IP，而这些IP地址并不是SLB的地址也不是NGINX的地址，而是来自于三个服务器内网的IP地址，于是确定了这些连接并不是来自于外部的请求。对三个IP地址进行了检测是来源于另外一个团队的三个主机调用的我们的http服务，然后针对这些连接状态的包进行了tcpdump，分析了发现全部都是http的keep-alive的包，说明三个服务器发起的连接并没有及时关掉，但是为什么要做keep-alive，而不是用完即关呢，这个原因是对方的团队根本就不知道，因为http默认了就是keep-alive。但是为什么服务器也没有主动断开呢？因为golang的http服务器默认是不限制keep-alive的时间的，于是对方团队增加了http的connection：close的header，后面就再也没有出现了这种问题。
其实总结下来，本身这个问题很容易解决，但是定位起来确实有点小麻烦的，要分析出这个问题大概在什么情况下会出现，又应该怎么确认和定位出根源来确实一个小小的挑战。不过出现这种问题目前也只是其中的一部分，在系统的不同阶段可能也会出现这种情况，如果真的高并发了，那可能就需要调整文件句柄数的参数了，也有可能要调整time wait的机制等等。
