一、概述

為了避免Elasticsearch性能不足，需要對默認參數做一些優化。

本文采用elasticsearch:7.10.1，切勿低於7.x版本。

二、系統層面調優

系統層面的調優主要是內存的設定與避免交換內存。

ES 安裝后默認設置的堆內存是 1GB，這很明顯是不夠的，那么接下來就會有一個問題出現：我們要設置多少內存給 ES 呢？

其實這是要看我們集群節點的內存大小，還取決於我們是否在服務器節點上還是否要部署其他服務。

如果內存相對很大，如 64G 及以上，並且我們不在 ES 集群上部署其他服務，那么我建議 ES 內存可以設置為 31G-32G，因為這里有一個 32G 性能瓶頸問題，直白的說就是即使你給了 ES 集群大於 32G 的內存，其性能也不一定會更加優良，甚至會不如設置為 31G-32G 時候的性能。
以我調優的集群為例，我所調優的服務器節點內存為 64G，服務器節點上也基本不跑其他服務，所以我把 ES 集群內存大小設置為了 31G，以充分發揮集群性能。

設置 ES 集群內存的時候，還有一點就是確保堆內存最小值（Xms）與最大值（Xmx）的大小是相同的，防止程序在運行時改變堆內存大小，這是一個很耗系統資源的過程。

還有一點就是避免交換內存，在操作系統層面進行關閉內存交換。

三、分配與副本

分片 (shard)：ES 是一個分布式的搜索引擎, 索引通常都會分解成不同部分, 分布在不同節點的部分數據就是分片。ES 自動管理和組織分片, 並在必要的時候對分片數據進行再平衡分配, 所以用戶基本上不用擔心分片的處理細節。創建索引時默認的分片數為 5 個，並且一旦創建不能更改。
副本 (replica)：ES 默認創建一份副本，就是說在 5 個主分片的基礎上，每個主分片都相應的有一個副本分片。額外的副本有利有弊，有副本可以有更強的故障恢復能力，但也占了相應副本倍數的磁盤空間。

那我們在創建索引的時候，應該創建多少個分片與副本數呢？

對於副本數，比較好確定，可以根據我們集群節點的多少與我們的存儲空間決定，我們的集群服務器多，並且有足夠大多存儲空間，可以多設置副本數，一般是 1-3 個副本數，如果集群服務器相對較少並且存儲空間沒有那么寬松，則可以只設定一份副本以保證容災（副本數可以動態調整）。
對於分片數，是比較難確定的。因為一個索引分片數一旦確定，就不能更改，所以我們在創建索引前，要充分的考慮到，以后我們創建的索引所存儲的數據量，否則創建了不合適的分片數，會對我們的性能造成很大的影響。

四、參數調優

elasticsearch.yml中增加如下設置

# 參數優化#######################################
indices.memory.index_buffer_size: 20%
indices.memory.min_index_buffer_size: 96mb

# Search pool
thread_pool.search.size: 5

indices.fielddata.cache.size: 40%

discovery.zen.fd.ping_timeout: 120s
discovery.zen.fd.ping_retries: 6
discovery.zen.fd.ping_interval: 30s

注意：我在參考文章的基礎上，刪除了一些參數。否則啟動會報錯，提示無效參數。

索引優化

PUT /_template/elk
{
      "order": 6,
      "template": "logstash-*",    #這里配置模板匹配的Index名稱
      "settings": {
        "number_of_replicas" : 1,    #副本數
        "number_of_shards" :   3,    #分片數
         "refresh_interval": "30s",
         "index.translog.durability": "async",
        "index.translog.sync_interval": "30s"

      }
}

elasticsearch.yml優化參數詳解

Indexing 緩沖大小

indices.memory.index_buffer_size: 20%
indices.memory.min_index_buffer_size: 96mb

已經索引好的文檔會先存放在內存緩存中，等待被寫到到段(segment)中。緩存滿的時候會觸發段刷盤(吃i/o和cpu的操作)。默認最小緩存大小為48m，不太夠，最大為堆內存的10%。對於大量寫入的場景也顯得有點小。

搜索線程池大小

thread_pool.search.size: 5

用於計數/搜索/建議操作。線程池類型是固定的自動隊列大小，大小為int類型，初始隊列大小為1000。

計算公式：（（cpu個數 * 3）/2）+1

設置filedata cache大小

indices.fielddata.cache.size: 40%

filedata cache的使用場景是一些聚合操作(包括排序),構建filedata cache是個相對昂貴的操作。所以盡量能讓他保留在內存中

然后日志場景聚合操作比較少，絕大多數也集中在半夜，所以限制了這個值的大小，默認是不受限制的，很可能占用過多的堆內存

設置節點之間的故障檢測配置

discovery.zen.fd.ping_timeout: 120s
discovery.zen.fd.ping_retries: 6
discovery.zen.fd.ping_interval: 30s

參數解釋

discovery.zen.fd.ping_interval 節點被 ping 的頻率，檢測節點是否存活
discovery.zen.fd.ping_timeout 節點存活響應的時間，默認為 30s，如果網絡可能存在隱患，可以適當調大
discovery.zen.fd.ping_retries ping 失敗/超時多少導致節點被視為失敗，默認為 3

大數量寫入的場景，會占用大量的網絡帶寬，很可能使節點之間的心跳超時。並且默認的心跳間隔也相對過於頻繁（1s檢測一次）

此項配置將大大緩解節點間的超時問題