問題背景：

近期針對(duì)老的PHP接口做了遷移重構(gòu)，用golang重新實(shí)現(xiàn)，在上線之前，測(cè)試進(jìn)行了壓測(cè)，壓測(cè)的量級(jí)為：200請(qǐng)求/s, 連續(xù)請(qǐng)求10s，發(fā)現(xiàn)接口出現(xiàn)大量超時(shí)錯(cuò)誤，查看日志發(fā)現(xiàn)錯(cuò)誤信息為：socket: too many open files （測(cè)試服務(wù)器配置：4核8G）

問題分析：

出現(xiàn)問題后，心里大概猜測(cè)是新版go接口使用了大量協(xié)程并發(fā)的去調(diào)用其他服務(wù)獲取數(shù)據(jù)，導(dǎo)致一瞬間將socket鏈接數(shù)占滿導(dǎo)致的

首先查看了系統(tǒng)的文件描述符打開限制, 為65535：

?然后讓測(cè)試幫忙重新壓測(cè)，查看項(xiàng)目進(jìn)程使用的文件描述符數(shù)量：

發(fā)現(xiàn)并沒有達(dá)到系統(tǒng)限制?

然后百度進(jìn)行查詢，才知道每個(gè)進(jìn)程有自己的文件描述限制，查看方式如下：

cat /proc/839357/limits

?可以看到，當(dāng)前項(xiàng)目進(jìn)程的文件描述限制為 1024， 那到這里，一下就明朗了，確實(shí)是文件描述符不夠用導(dǎo)致的

那么問題來(lái)了，這個(gè)進(jìn)程的文件描述符石誰(shuí)來(lái)控制的呢，我想到我們的go服務(wù)使用守護(hù)進(jìn)程來(lái)進(jìn)行統(tǒng)一管理的，百度查詢后了解到，守護(hù)進(jìn)程有一個(gè)默認(rèn)的文件描述符配置，初始值為1024，不做修改的話，守護(hù)進(jìn)程啟動(dòng)的每個(gè)服務(wù)，文件描述限制都是1024，如下圖：

問題解決：

?為了臨時(shí)解決此問題，決定修改為65535，發(fā)現(xiàn)改了配置之后，reload、update都不生效，必須重啟守護(hù)進(jìn)程，這里要特別注意

因?yàn)榫€上守護(hù)進(jìn)程不能隨意重啟，所以通過(guò)代碼修改了此配置，代碼如下：

syscall.Setrlimit(syscall.RLIMIT_NOFILE, &syscall.Rlimit{Max: 65535,Cur: 65535,
})

至此，這個(gè)問題算是臨時(shí)解決，可以正常上線

深層次思考：

通過(guò)這個(gè)問題，可以看出系統(tǒng)本身的抗并發(fā)能力很弱，所以上線后又進(jìn)行一次具體的分析，分析思路如下：

• 模擬壓測(cè)請(qǐng)求，查看并發(fā)情況下，開啟的協(xié)程數(shù)量 （基本協(xié)程的使用都是請(qǐng)求其他服務(wù)的接口，通過(guò)這個(gè)來(lái)看對(duì)其他服務(wù)的并發(fā)調(diào)用情況）
• 查看依賴服務(wù)主要接口的抗并發(fā)能力，在并發(fā)量大的情況下，依賴服務(wù)是否存在問題從而影響web端
• 調(diào)用其他服務(wù)是否使用了連接池，tcp是否進(jìn)行了復(fù)用，鏈接是否正常關(guān)閉
• 調(diào)用其他服務(wù)是否有做超時(shí)熔斷以此來(lái)保證當(dāng)前服務(wù)的穩(wěn)定性
• 當(dāng)前服務(wù)是否有做限流控制，當(dāng)并發(fā)超過(guò)承受能力后，新的流量只會(huì)機(jī)器壓力更大導(dǎo)致服務(wù)出現(xiàn)更多的問題
• 對(duì)攜程的使用是否要加以控制，比如使用協(xié)程池

go萌新一枚，后續(xù)的線上問題以及解決過(guò)程會(huì)持續(xù)更新

下篇文章會(huì)針對(duì)各項(xiàng)思考去逐個(gè)分析