ElasticSearch優化方式
阿新 • • 發佈：2019-10-03
- ES每個分片是一個Lucence例項，所以分片數量不應過多。但是分片數一旦設定好就不能修改，如果設定過少等資料量上去後不能擴容，這時可以考慮增加索引庫的方式來增加分片數。比如一個索引庫設定20個分片，增加一個索引庫就等於增加了20個分片。應用程式如何知道增加了索引庫呢？這時需要用到ES的別名功能，將一個別名對映到多個實際的索引庫，而應用程式使用別名即可，別名對映的實際索引庫可以動態修改而對應用程式透明。
- 可以從這幾個方面來觀測ES的效能指標：
- cpu消耗
- 記憶體消耗
- 磁碟io和網路io
- jvm的gc情況
- es的各個執行緒池和佇列的負荷
- Elasticsearch 需要使用大量的堆記憶體, 而 Lucene 則需要消耗大量非堆記憶體 (off-heap)。推薦給 ES 設定本機記憶體的一半, 如32G 記憶體的機器上, 設定 -Xmx16g -Xms16g ，剩下的記憶體給 Lucene 。
- 如果不需要對分詞字串做聚合計算（例如，不需要 fielddata ）可以考慮降低堆記憶體。堆記憶體越小，Elasticsearch（更快的 GC）和 Lucene（更多的記憶體用於快取）的效能越好。
- 針對io高的優化方式：
- 儘量保證一個分片只落在一個硬碟上面，這樣不用跨磁碟讀寫
- 檢查mapping，es預設會將所有欄位寫入_all欄位，如果實際業務不需要可以關閉，減少儲存空間
- 同樣的，如果不需要儲存原始資料，可以關閉_source，或者只設置某些必要欄位的store屬性 store:true
- 查詢時只返回必要的資料
- 採用_doc排序可以依賴lucence內部id排序，提高排序速度
- 注意防止腦裂：
-
discovery.zen.minimum_master_nodes > = ( master 候選節點個數 / 2) + 1
-
- 如果有節點掛掉，不要急於恢復叢集導致分片資料的大量複製和傳輸，應儘量等節點自己恢復：
-
gateway.recover_after_nodes: 8 # 等待叢集至少存在 8 個節點 後才能進行資料恢復 gateway.expected_nodes: 10 gateway.recover_after_time: 5m # 等待 5 分鐘，或者 10 個節點上線後，才進行資料恢復，這取決於哪個條件先達到
-
- 升級的過程因為需要關閉節點再重啟，這時也要防止es自動恢復的操作：
- 可能的話，停止索引新的資料
- 禁止分片分配，這樣es不會自動平衡缺失的分片：
-
PUT /_cluster/settings { "transient" : { "cluster.routing.allocation.enable" : "none" } }
-
- 這時關閉節點，升級好後再加入叢集，然後重啟分片分配即可：
- "cluster.routing.allocation.enable" : "all"
- 可以考慮在ES前面加一個kafka之類的訊息快取，防止資料量的瞬間暴增對es