? 最近生產(chǎn)環(huán)境頻繁報出too many open files，導(dǎo)致系統(tǒng)無法對外提供服務(wù)剂公。
? 該系統(tǒng)采用golang開發(fā)起便，但是并發(fā)量并不大，而是一個小型的內(nèi)部管理系統(tǒng)狞洋，按理說默認的1024的文件句柄數(shù)是完全夠用的弯淘，本來團隊人員有提出增加文件句柄數(shù)來解決問題。我的想法是1024對于小型的沒什么并發(fā)量的系統(tǒng)是完全夠用的吉懊，不需要增加句柄數(shù)來解決問題庐橙，而且增加了只是治標(biāo)不治本，必須找到根源才可以借嗽。
? 于是我們開始定位問題态鳖，查找的思路是第一步確定系統(tǒng)中是否有http請求鏈接是否存在沒有主動關(guān)閉的鏈接，于是針對調(diào)用外部的http的地方進行了排查和測試恶导，結(jié)果都是正常的浆竭，說明本身自己的代碼是沒有問題的；第二步查詢服務(wù)器上的tcp狀態(tài)惨寿，發(fā)現(xiàn)有大概幾百的time_wait的狀態(tài)邦泄，但是time_wait的狀態(tài)屬于服務(wù)器主動斷開才會出現(xiàn)的，說明服務(wù)器確實有很多連接裂垦，但是幾百的time_wait也不會導(dǎo)致too many open files的問題顺囊。于是進一步分析established的信息，發(fā)現(xiàn)有大量的連接蕉拢，而且分析下來發(fā)現(xiàn)客戶端IP地址都是來源于三個固定IP包蓝，而這些IP地址并不是SLB的地址也不是NGINX的地址，而是來自于三個服務(wù)器內(nèi)網(wǎng)的IP地址企量，于是確定了這些連接并不是來自于外部的請求测萎。對三個IP地址進行了檢測是來源于另外一個團隊的三個主機調(diào)用的我們的http服務(wù)，然后針對這些連接狀態(tài)的包進行了tcpdump届巩，分析了發(fā)現(xiàn)全部都是http的keep-alive的包硅瞧，說明三個服務(wù)器發(fā)起的連接并沒有及時關(guān)掉，但是為什么要做keep-alive恕汇，而不是用完即關(guān)呢腕唧，這個原因是對方的團隊根本就不知道，因為http默認了就是keep-alive瘾英。但是為什么服務(wù)器也沒有主動斷開呢枣接？因為golang的http服務(wù)器默認是不限制keep-alive的時間的，于是對方團隊增加了http的connection：close的header缺谴，后面就再也沒有出現(xiàn)了這種問題但惶。
? 其實總結(jié)下來，本身這個問題很容易解決，但是定位起來確實有點小麻煩的膀曾，要分析出這個問題大概在什么情況下會出現(xiàn)县爬，又應(yīng)該怎么確認和定位出根源來確實一個小小的挑戰(zhàn)。不過出現(xiàn)這種問題目前也只是其中的一部分添谊，在系統(tǒng)的不同階段可能也會出現(xiàn)這種情況财喳，如果真的高并發(fā)了，那可能就需要調(diào)整文件句柄數(shù)的參數(shù)了斩狱，也有可能要調(diào)整time wait的機制等等耳高。
