Elasticsearch實戰-磁盤IO被打滿

背景

事情是這樣的。一天下午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只處理複雜查詢請求。