Elasticsearch：深入集群優化

01-26

為打造一個高查詢和高索引吞吐量、高穩定性的 Elasticsearch 集群，相信以下幾點配置優化都很重要。

1、設置Java堆大小

-Xmx和-Xms設置成同樣的值，例如16G

不宜超過物理內存的一半，比如伺服器是32G，Heap大小可以設置為16G，官方說了，不要設置太大超過32G，可能導致長GC。

2、索引日常維護

日常維護也是一個很重要的工作，不僅僅可以釋放內存、節省磁碟空間，還可以加快檢索速率

1）刪除過期索引

2）關閉日常沒有搜索的索引

3）不更新的索引可以進行強制合併

3、Index刷寫速率配置

調整索引刷新頻率，但是不能太小。太小會造成索引頻繁刷新，新的數據寫進去就慢了，索引速度也並不一定就快。

可以提高提吐量：

index.refresh_interval:15s

4、可以分開配置主節點和數據節點

儘可能保持高可用，設置 node.master和node.data，這樣大家職責清楚，要麼接受主節點（只接受請求和管理節點）和數據節點（只存儲數據）

例如在： elasticsearch.yml配置數據節點

node.master: false

node.data: true

5、主節點選取的配置：防止腦裂

所謂腦裂問題（類似於精神分裂），就是同一個集群中的不同節點，對於集群的狀態有了不一樣的理解。集群如果6個節點，故障恢復後，有時候可能會形成2個--3節點的集群，導致不能正常工作。

可能導致的原因：

1.）網路：由於是內網通信，網路通信問題造成某些節點認為master死掉，而另選master的可能性較小；進而檢查Ganglia集群監控，也沒有發現異常的內網流量，故此原因可以排除。

2.）節點負載：由於master節點與data節點都是混合在一起的，所以當工作節點的負載較大（確實也較大）時，導致對應的ES實例停止響應，而這台伺服器如果正充當著master節點的身份，那麼一部分節點就會認為這個master節點失效了，故重新選舉新的節點，這時就出現了腦裂；同時由於data節點上ES進程佔用的內存較大，較大規模的內存回收操作也能造成ES進程失去響應。所以，這個原因的可能性應該是最大的。

解決方法：

discovery.zen.minimum_master_nodes屬性，連接節點的最小數目

設置為所有可用節點個數加1的50%（如果6個節點數量，官方的推薦值是(N/2)+1，就是4），將只會有一個4節點的集群。另外2個無法組成一個集群，只能等待重新連接會到集群。

6、配置單播和多播

使用單播時，總是設置discovery.zen.ping.multicast.enabled為false。

7、節點ping設置，更多等待時間設置

discovery.zen.fd.ping_interval：該屬性默認為1s（1秒鐘），指定了節點互相ping的時間間隔。

? discovery.zen.fd.ping_timeout：該屬性默認為30s（30秒鐘），指定了節點發送ping信息後等待響應的時間，超過此時間則認為對方節點無響應。

? discovery.zen.fd.ping_retries：該屬性默認為3，指定了重試次數，超過此次數則認為對方節點已停止工作。

希望對大家有幫助，謝謝。