Elasticsearch實戰-磁碟IO被打滿

• 2019 年 10 月 6 日
• 筆記

背景

事情是這樣的。一天下午4點42分左右。業務回饋我開發的服務在測試環境出現問題，返回資源數據是0。查日誌發現是ES訪問超時。相當於資料庫掛了。持續了20多分鐘自己恢復。
諮詢了ES團隊，最終得到下面的答覆：

當前集群現狀:  1）當前集群數據IO最高的索引為XXX，數據量很小(100mb)  2)但是讀寫都很大(讀>1000QPS,寫>1000QPS) ，使用的是線下環境的機器  3)索引分了10個片，4個副本問題  分析:  1)線下環境的機器之前了解到測試環境硬碟性能本來就很差,這個需要業務SRE一塊來確定  2)查詢的時候，會一次性查詢10個片，這樣可能會查10台機器的數據，很容易出現木桶效應，造成集群的性能下降  3)寫入的時候，雖然是做了10個分片，看起來能加大寫能力，但是機器數少，導致結果是每台機器分布了5個分片，等效於只做了2個分片，完全沒有擴大寫的能力  建議:  1)升級硬體，換成SSD  2)分片改成2個，這樣讀能力比以前肯定有提升，寫能力等價  3)數據量很小，建議直接換成Redis

我自己做了調查。測試環境ES有十台VM（非本地ESB磁碟）作為伺服器。其中一台IO被打滿。其他機器負載、IO都很低。對於這個問題，ES團隊給出的答覆是：

ES的服務負載均衡、發現機制是自己寫的，一般不會出現問題，  Client僅僅對官方的客戶端做了簡單的封裝，  當然最好是可以對官方的客戶端進行改造，  但是我們現在的人力明顯不行，只能繼續沿用老的客戶端使用；  我們預計在10月份左右會出一個自研的客戶端，  會盡量避免出現一台機器導致部分查詢出現問題，  但是也避免不了，  ES內部的服務發現機制，我們改變不了，除非改ES

調查

1.需要換成本地磁碟，測試環境也是我們的正式環境。是否能直接替換成物理機？多少台合適？怎麼可以平滑替換？

沒有必要換成物理機。因為ES記憶體最多能用32G。記憶體多出來的是浪費用不上，有物理機也是隔成VM來用。

原來10台VM是足夠的，只需要同等數量替換。

有機器替換功能。替換時原理是先申請機器部署。然後點擊機器替換。會一台台的將分片趕到新機器上。一台下完自動下線老機器。

2.我們測試環境有10台伺服器，10個分片，4個副本，寫/讀QPS大概是7：6。究竟幾個分片幾個索引更合理？

因為每個分片和副本是同步寫。寫比例大，副本多會對性能有很大影響。分片替換需要重建索引，很難平滑。所以只將副本數減少為一個分片1個。

3.程式方面有沒有可以優化的？

在ES上層增加tair快取。在進行數據更新操作時是單個數據讀取。採用tair有更好的事務性，並減少了對ES的壓力。ES只處理複雜查詢請求。