今天線上遇到一個(gè)問(wèn)題，我有個(gè)服務(wù)調(diào)es做curd, 有一段時(shí)間服務(wù)突然不接收請(qǐng)求，進(jìn)程還活著，就是單純的請(qǐng)求進(jìn)不來(lái)了，但是過(guò)了一會(huì)兒又好了。排查了一下故障前后有大量的請(qǐng)求丟棄（服務(wù)是rpc調(diào)用，服務(wù)端有4個(gè)隊(duì)列每個(gè)隊(duì)列32線程），觀察到隊(duì)列中有很多請(qǐng)求等待時(shí)間過(guò)長(zhǎng)。
服務(wù)當(dāng)時(shí)是這樣的：

瞬間一段時(shí)間（18:19）就沒(méi)有流量了，然而進(jìn)程還在。
后來(lái)莫名其妙自己又活了，但是活了以后瞬間并發(fā)量上來(lái)了。

因?yàn)榉?wù)影響面積大，問(wèn)題出現(xiàn)瞬間我嘗試重啟服務(wù)，但是并沒(méi)什么用，起來(lái)后收到幾次請(qǐng)求立馬又假死了。

排查的過(guò)程中，在日志里面又看到 有少數(shù)請(qǐng)求調(diào)用時(shí)間非常久，估計(jì)是因?yàn)檫@個(gè)導(dǎo)致所有線程都被占滿了，騰不出更多的空來(lái)接受新的請(qǐng)求了。

可以確保不是網(wǎng)絡(luò)問(wèn)題，因?yàn)檫@一段時(shí)間服務(wù)器是有出口流量的，找運(yùn)維同學(xué)看過(guò)監(jiān)控了。

另外，這一段時(shí)間的內(nèi)存稍微吃的有點(diǎn)多，但是沒(méi)有出現(xiàn)大面積全GC，個(gè)人覺(jué)得不太像是全GC導(dǎo)致的，至少GC日志看不到FullGC 字樣，只是cms gc回收老年代頻率高了點(diǎn)。

這個(gè)rpc服務(wù) 里面是調(diào)用elasticsearch做增刪改查業(yè)務(wù)的，調(diào)用量挺高的，不過(guò)出問(wèn)題的時(shí)候是低峰期，我覺(jué)得唯一的解釋就是這一會(huì)兒存在一些 查詢或者修改很慢的請(qǐng)求占用了這128個(gè)線程不釋放。

好了，問(wèn)題和我自己的假設(shè)已經(jīng)敘述完了， 如果我的假設(shè)成立的話，那么優(yōu)化方向似乎就變成了：如何提升請(qǐng)求響應(yīng)速度，進(jìn)而演變?yōu)榱耍喝绾翁嵘齟lasticsearch 的增刪改查效率（的確，線上環(huán)境再一些高峰期的時(shí)候，會(huì)出現(xiàn)一些刪改查比較慢的請(qǐng)求，但es的刪改查效率原本也不高），這塊的優(yōu)化方案是我想問(wèn)大伙兒的。

另外，是不是需要設(shè)置增刪改查和es交互這塊的超時(shí)時(shí)間，比如es api里面有 get(timeout)這種方法，但是我又不知道這個(gè)數(shù)設(shè)置多少是合適的，這塊也是我想問(wèn)的。

超時(shí)這個(gè)問(wèn)題上，是不是在es api客戶端也要做文章，有沒(méi)有可能是我調(diào)用es 客戶單發(fā)起請(qǐng)求，但是每次請(qǐng)求完我并沒(méi)有close，這樣導(dǎo)致鏈接長(zhǎng)時(shí)間不釋放，阻塞了es集群，導(dǎo)致很多es操作時(shí)間其實(shí)并不長(zhǎng)，但是都浪費(fèi)在了等待es服務(wù)端接受請(qǐng)求上。不過(guò)貌似TransportClient是做了連接池的吧，這樣還需要我手動(dòng)close鏈接嗎？這也是我想問(wèn)的。

最后，大家?guī)兔Ψ治鱿?，這種假死行為還有沒(méi)有可能是別的原因，由于事發(fā)緊急，沒(méi)來(lái)得及捕獲更多信息，我能保證的是內(nèi)存和cpu還是足夠的，機(jī)器監(jiān)控記錄能看到。網(wǎng)絡(luò)OK的，進(jìn)程沒(méi)有死。

有遇到類似問(wèn)題的同學(xué),歡迎一起探討。