在生產(chǎn)環(huán)境搭建或維護(hù) Elasticsearch 集群和個(gè)人搭建集群的小打小鬧有非常大的不同。

本文的最佳實(shí)踐基于每天增量數(shù)億+ 的線上環(huán)境。

少啰嗦，上干貨。

1、內(nèi)存

Elasticsearch 和 Lucene 都是 Java 語(yǔ)言編寫(xiě)，這意味著我們必須注意堆內(nèi)存的設(shè)置。

Elasticsearch 可用的堆越多，它可用于過(guò)濾器（filter）和其他緩存的內(nèi)存也就越多，更進(jìn)一步講可以提高查詢性能。

但請(qǐng)注意，過(guò)多的堆可能會(huì)使垃圾回收暫停時(shí)間過(guò)長(zhǎng)。請(qǐng)勿將堆內(nèi)存的最大值設(shè)置為 JVM 用于壓縮對(duì)象指針（壓縮的 oops）的臨界值之上，確切的臨界值有所不同，但不要超過(guò) 32 GB。

推薦：干貨 | 吃透Elasticsearch 堆內(nèi)存

常見(jiàn)內(nèi)存配置坑 1：堆內(nèi)存設(shè)置過(guò)大

舉例：Elasticsearch 宿主機(jī)：64 GB 內(nèi)存，堆內(nèi)存恨不得設(shè)置為 64 GB。

但，這忽略了堆的另一部分內(nèi)存使用大戶：OS 文件緩存。

Lucene 旨在利用底層操作系統(tǒng)來(lái)緩存內(nèi)存中的數(shù)據(jù)結(jié)構(gòu)。Lucene 段存儲(chǔ)在單獨(dú)的文件中。

由于段是不可變的（immutable），因此這些文件永遠(yuǎn)不會(huì)更改。這使它們非常易于緩存，并且底層操作系統(tǒng)很樂(lè)意將熱段駐留在內(nèi)存中，以加快訪問(wèn)速度。

這些段包括倒排索引（用于全文搜索）和doc values 正排索引（用于聚合）。Lucene 的性能取決于與 OS 文件緩存的交互。

如果你將所有可用內(nèi)存分配給 Elasticsearch 的堆，則 OS 文件緩存將不會(huì)剩下任何可用空間。這會(huì)嚴(yán)重影響性能。

官方標(biāo)準(zhǔn)建議是：將 50％ 的可用內(nèi)存（不超過(guò) 32 GB，一般建議最大設(shè)置為：31 GB）分配給 Elasticsearch 堆，而其余 50％ 留給 Lucene 緩存。

圖片來(lái)自網(wǎng)絡(luò)

可以通過(guò)以下方式配置 Elasticsearch 堆：

• 方式一：堆內(nèi)存配置文件 jvm.options

# Xms represents the initial size of total heap space
# Xmx represents the maximum size of total heap space
-Xms16g
-Xmx16g

• 方式二：?jiǎn)?dòng)參數(shù)設(shè)置

ES_JAVA_OPTS="-Xms10g -Xmx10g" ./bin/elasticsearch

2、CPU

運(yùn)行復(fù)雜的緩存查詢、密集寫(xiě)入數(shù)據(jù)都需要大量的CPU，因此選擇正確的查詢類型以及漸進(jìn)的寫(xiě)入策略至關(guān)重要。

一個(gè)節(jié)點(diǎn)使用多個(gè)線程池來(lái)管理內(nèi)存消耗。與線程池關(guān)聯(lián)的隊(duì)列使待處理的請(qǐng)求得以保留（類似緩沖效果）而不是被丟棄。

由于 Elasticsearch會(huì)做動(dòng)態(tài)分配，除非有非常具體的要求，否則不建議更改線程池和隊(duì)列大小。

線程池和隊(duì)列的設(shè)置，參見(jiàn)：

Elasticsearch 線程池和隊(duì)列問(wèn)題，請(qǐng)先看這一篇。

推薦閱讀：

https://www.elastic.co/guide/en/elasticsearch/reference/current/modules-threadpool.html

3、分片數(shù)

分片是 Elasticsearch 在集群內(nèi)分發(fā)數(shù)據(jù)的單位。集群發(fā)生故障再恢復(fù)平衡的速度取決于分片的大小、分片數(shù)量、網(wǎng)絡(luò)以及磁盤(pán)性能。

在 Elasticsearch 中，每個(gè)查詢?cè)诿總€(gè)分片的單個(gè)線程中執(zhí)行。但是，可以并行處理多個(gè)分片。針對(duì)同一分片的多個(gè)查詢和聚合也可以并行處理。

這意味著在不涉及緩存的情況下，最小查詢延遲將取決于數(shù)據(jù)、查詢類型以及分片的大小三個(gè)因素。

3.1 設(shè)置很多小分片 VS 設(shè)置很少大分片？

• 查詢很多小分片，導(dǎo)致每個(gè)分片能做到快速響應(yīng)，但是由于需要按順序排隊(duì)和處理結(jié)果匯集。因此不一定比查詢少量的大分片快。

• 如果存在多個(gè)并發(fā)查詢，那么擁有大量小分片也會(huì)降低查詢吞吐量。

所以，就有了下面的分片數(shù)如何設(shè)定的問(wèn)題？

3.2 分片數(shù)設(shè)定

選擇正確數(shù)量的分片是一個(gè)復(fù)雜問(wèn)題，因?yàn)樵诩阂?guī)劃階段以及在數(shù)據(jù)寫(xiě)入開(kāi)始之前，一般不能確切知道文檔數(shù)。

對(duì)于集群而言，分片數(shù)多了以后，索引和分片管理可能會(huì)使主節(jié)點(diǎn)超載，并可能會(huì)導(dǎo)致集群無(wú)響應(yīng)，甚至導(dǎo)致集群宕機(jī)。

建議：為主節(jié)點(diǎn)（Master 節(jié)點(diǎn)）分配足夠的資源以應(yīng)對(duì)分片數(shù)過(guò)多可能導(dǎo)致的問(wèn)題。

必須強(qiáng)調(diào)的是：主分片數(shù)是在索引創(chuàng)建時(shí)定義的，不支持借助 update API 實(shí)現(xiàn)類副本數(shù)更新的動(dòng)態(tài)修改。創(chuàng)建索引后，更改主分片數(shù)的唯一方法是重新創(chuàng)建索引，然后將原來(lái)索引數(shù)據(jù) reindex 到新索引。

官方給出的合理的建議：每個(gè)分片數(shù)據(jù)大?。?/span>30GB-50GB。

推薦1：Elasticsearch究竟要設(shè)置多少分片數(shù)？

https://elastic.blog.csdn.net/article/details/78080602

推薦2：Elasticsearch之如何合理分配索引分片

https://qbox.io/blog/optimizing-elasticsearch-how-many-shards-per-index

4、副本

Elasticsearch 通過(guò)副本實(shí)現(xiàn)集群的高可用性，數(shù)據(jù)在數(shù)據(jù)節(jié)點(diǎn)之間復(fù)制，以實(shí)現(xiàn)主分片數(shù)據(jù)的備份，因此即便部分節(jié)點(diǎn)因異常下線也不會(huì)導(dǎo)致數(shù)據(jù)丟失。

默認(rèn)情況下，副本數(shù)為 1，但可以根據(jù)產(chǎn)品高可用要求將其增加。副本越多，數(shù)據(jù)的容災(zāi)性越高。

副本多的另一個(gè)優(yōu)點(diǎn)是，每個(gè)節(jié)點(diǎn)都擁有一個(gè)副本分片，有助于提升查詢性能。

銘毅提醒：

• 實(shí)際副本數(shù)增多提高查詢性能建議結(jié)合集群做下測(cè)試，我實(shí)測(cè)過(guò)效果不明顯。

• 副本數(shù)增多意味著磁盤(pán)存儲(chǔ)要加倍，也考驗(yàn)硬盤(pán)空間和磁盤(pán)預(yù)算。

建議：根據(jù)業(yè)務(wù)實(shí)際綜合考慮設(shè)置副本數(shù)。普通業(yè)務(wù)場(chǎng)景（非精準(zhǔn)高可用）副本設(shè)置為 1 足夠了。

5、冷熱集群架構(gòu)配置

根據(jù)產(chǎn)品業(yè)務(wù)數(shù)據(jù)特定和需求，我們可以將數(shù)據(jù)分為熱數(shù)據(jù)和冷數(shù)據(jù)，這是冷熱集群架構(gòu)的前提。

訪問(wèn)頻率更高的索引可以分配更多更高配（如：SSD）的數(shù)據(jù)節(jié)點(diǎn)，而訪問(wèn)頻率較低的索引可以分配低配（如：機(jī)械磁盤(pán)）數(shù)據(jù)節(jié)點(diǎn)。

冷熱集群架構(gòu)對(duì)于存儲(chǔ)諸如應(yīng)用程序日志或互聯(lián)網(wǎng)實(shí)時(shí)采集數(shù)據(jù)（基于時(shí)間序列數(shù)據(jù)）特別有用。

數(shù)據(jù)遷移策略：通過(guò)運(yùn)行定時(shí)任務(wù)來(lái)實(shí)現(xiàn)定期將索引移動(dòng)到不同類型的節(jié)點(diǎn)。

具體實(shí)現(xiàn)：curator 工具或借助 ILM 索引生命周期管理。

5.1 熱節(jié)點(diǎn)

熱節(jié)點(diǎn)是一種特定類型的數(shù)據(jù)節(jié)點(diǎn)，關(guān)聯(lián)索引數(shù)據(jù)是：最近、最新、最熱數(shù)據(jù)。

因?yàn)檫@些熱節(jié)點(diǎn)數(shù)據(jù)通常傾向于最頻繁地查詢。熱數(shù)據(jù)的操作會(huì)占用大量 CPU 和 IO 資源，因此對(duì)應(yīng)服務(wù)器需要功能強(qiáng)大（高配）并附加 SSD 存儲(chǔ)支持。

針對(duì)集群規(guī)模大的場(chǎng)景，建議：至少運(yùn)行 3 個(gè)熱節(jié)點(diǎn)以實(shí)現(xiàn)高可用性。

當(dāng)然，這也和你實(shí)際業(yè)務(wù)寫(xiě)入和查詢的數(shù)據(jù)量有關(guān)系，如果數(shù)據(jù)量非常大，可能會(huì)需要增加熱節(jié)點(diǎn)數(shù)目。

5.2 冷節(jié)點(diǎn)（或稱暖節(jié)點(diǎn)）

冷節(jié)點(diǎn)是對(duì)標(biāo)熱節(jié)點(diǎn)的一種數(shù)據(jù)節(jié)點(diǎn)，旨在處理大量不太經(jīng)常查詢的只讀索引數(shù)據(jù)。

由于這些索引是只讀的，因此冷節(jié)點(diǎn)傾向于使用普通機(jī)械磁盤(pán)而非 SSD 磁盤(pán)。

與熱節(jié)點(diǎn)對(duì)標(biāo)，也建議：最少 3 個(gè)冷節(jié)點(diǎn)以實(shí)現(xiàn)高可用性。

同樣需要注意的是，若集群規(guī)模非常大，可能需要更多節(jié)點(diǎn)才能滿足性能要求。

甚至需要更多類型，如：熱節(jié)點(diǎn)、暖節(jié)點(diǎn)、冷節(jié)點(diǎn)等。

強(qiáng)調(diào)一下：CPU 和 內(nèi)存的分配最終需要你通過(guò)使用與生產(chǎn)環(huán)境中類似的環(huán)境借助 esrally 性能測(cè)試工具測(cè)試確定，而不是直接參考各種最佳實(shí)踐拍腦袋而定。

有關(guān)熱節(jié)點(diǎn)和熱節(jié)點(diǎn)的更多詳細(xì)信息，請(qǐng)參見(jiàn)：

https://www.elastic.co/blog/hot-warm-architecture-in-elasticsearch-5-x

推薦：冷熱集群架構(gòu)實(shí)戰(zhàn)

6、節(jié)點(diǎn)角色劃分

Elasticsearch 節(jié)點(diǎn)核心可分為三類：主節(jié)點(diǎn)、數(shù)據(jù)節(jié)點(diǎn)、協(xié)調(diào)節(jié)點(diǎn)。

6.1 主節(jié)點(diǎn)

主節(jié)點(diǎn)：如果主節(jié)點(diǎn)是僅是候選主節(jié)點(diǎn)，不含數(shù)據(jù)節(jié)點(diǎn)角色，則它配置要求沒(méi)有那么高，因?yàn)樗淮鎯?chǔ)任何索引數(shù)據(jù)。

如前所述，如果分片非常多，建議主節(jié)點(diǎn)要提高硬件配置。

主節(jié)點(diǎn)職責(zé)：存儲(chǔ)集群狀態(tài)信息、分片分配管理等。

同時(shí)注意，Elasticsearch 應(yīng)該有多個(gè)候選主節(jié)點(diǎn)，以避免腦裂問(wèn)題。

6.2 數(shù)據(jù)節(jié)點(diǎn)

數(shù)據(jù)節(jié)點(diǎn)職責(zé)：CURD、搜索以及聚合相關(guān)的操作。

這些操作一般都是IO、內(nèi)存、CPU 密集型。

6.3 協(xié)調(diào)節(jié)點(diǎn)

協(xié)調(diào)節(jié)點(diǎn)職責(zé)：類似負(fù)載平衡器，主要工作是：將搜索任務(wù)分發(fā)到相關(guān)的數(shù)據(jù)節(jié)點(diǎn)，并收集所有結(jié)果，然后再將它們匯總并返回給客戶端應(yīng)用程序。

6.4 節(jié)點(diǎn)配置參考

下表參見(jiàn)官方博客 PPT

6.5 不同節(jié)點(diǎn)角色配置如下

必須配置到：elasticsearch.yml 中。

• 主節(jié)點(diǎn)

node.master:true 
node.data:false 

• 數(shù)據(jù)節(jié)點(diǎn)

node.master:false 
node.data:true 

• 協(xié)調(diào)節(jié)點(diǎn)

node.master:false 
node.data:false

7、故障排除提示

Elasticsearch 的性能在很大程度上取決于宿主機(jī)資源情況。

CPU、內(nèi)存使用率和磁盤(pán) IO 是每個(gè)Elasticsearch節(jié)點(diǎn)的基本指標(biāo)。

建議你在CPU使用率激增時(shí)查看Java虛擬機(jī)（JVM）指標(biāo)。

7.1 堆內(nèi)存使用率高

高堆內(nèi)存使用率壓力以兩種方式影響集群性能：

7.1.1 堆內(nèi)存壓力上升到75％及更高

剩余可用內(nèi)存更少，并且集群現(xiàn)在還需要花費(fèi)一些 CPU 資源以通過(guò)垃圾回收來(lái)回收內(nèi)存。

在啟用垃圾收集時(shí)，這些 CPU 周期不可用于處理用戶請(qǐng)求。結(jié)果，隨著系統(tǒng)變得越來(lái)越受資源約束，用戶請(qǐng)求的響應(yīng)時(shí)間增加。

7.1.2 堆內(nèi)存壓力繼續(xù)上升并達(dá)到接近100％

將使用更具侵略性的垃圾收集形式，這將反過(guò)來(lái)極大地影響集群響應(yīng)時(shí)間。

索引響應(yīng)時(shí)間度量標(biāo)準(zhǔn)表明，高堆內(nèi)存壓力會(huì)嚴(yán)重影響性能。

7.2 非堆內(nèi)存使用率增長(zhǎng)

JVM 外非堆內(nèi)存的增長(zhǎng)，吞噬了用于頁(yè)面緩存的內(nèi)存，并可能導(dǎo)致內(nèi)核級(jí)OOM。

7.3 監(jiān)控磁盤(pán)IO

由于Elasticsearch大量使用存儲(chǔ)設(shè)備，磁盤(pán) IO 的監(jiān)視是所有其他優(yōu)化的基礎(chǔ)，發(fā)現(xiàn)磁盤(pán) IO 問(wèn)題并對(duì)相關(guān)業(yè)務(wù)操作做調(diào)整可以避免潛在的問(wèn)題。

應(yīng)根據(jù)引起磁盤(pán) IO 的情況評(píng)估對(duì)策，常見(jiàn)優(yōu)化磁盤(pán) IO 實(shí)戰(zhàn)策略如下：

• 優(yōu)化分片數(shù)量及其大小
• 段合并策略優(yōu)化
• 更換普通磁盤(pán)為SSD磁盤(pán)
• 添加更多節(jié)點(diǎn)

7.5 合理設(shè)置預(yù)警

對(duì)于依賴搜索的應(yīng)用程序，用戶體驗(yàn)與搜索請(qǐng)求的等待時(shí)間長(zhǎng)短相關(guān)。

有許多因素會(huì)影響查詢性能，例如：

• 構(gòu)造查詢方式不合理
• Elasticsearch 集群配置不合理
• JVM 內(nèi)存和垃圾回收問(wèn)題
• 磁盤(pán) IO 等

查詢延遲是直接影響用戶體驗(yàn)的指標(biāo)，因此請(qǐng)確保在其上放置一些預(yù)警操作。

舉例：線上實(shí)戰(zhàn)問(wèn)題：

如何避免?  以下兩個(gè)核心配置供參考：

PUT _cluster/settings
{
  "transient": {
    "search.default_search_timeout": "50s",
    "search.allow_expensive_queries": false
  }
}

需要強(qiáng)調(diào)的是："search.allow_expensive_queries"  是 7.7+ 版本才有的功能，早期版本會(huì)報(bào)錯(cuò)。

推薦閱讀：

https://www.elastic.co/guide/en/elasticsearch/reference/current/query-dsl-wildcard-query.html

https://www.elastic.co/guide/en/elasticsearch/reference/current/search-your-data.html

7.6 合理配置緩存

默認(rèn)情況下，Elasticsearch中的大多數(shù)過(guò)濾器都是高速緩存的。

這意味著在第一次執(zhí)行過(guò)濾查詢時(shí)，Elasticsearch 將查找與過(guò)濾器匹配的文檔，并使用該信息構(gòu)建名為“bitset”的結(jié)構(gòu)。

存儲(chǔ)在 bitset 中的數(shù)據(jù)包含文檔標(biāo)識(shí)符以及給定文檔是否與過(guò)濾器匹配。

具有相同過(guò)濾器的查詢的后續(xù)執(zhí)行將重用存儲(chǔ)在bitset中的信息，從而通過(guò)節(jié)省 IO 操作和 CPU 周期來(lái)加快查詢的執(zhí)行速度。

建議在查詢中使用 filter 過(guò)濾器。

有關(guān)更多詳細(xì)信息，請(qǐng)參見(jiàn)：

1. 吃透 | Elasticsearch filter和query的不同

2. Elasticsearch 緩存深入詳解
   

7.7 合理設(shè)置刷新頻率

刷新頻率（refresh_interval）和段合并頻率與索引性能密切相關(guān)，此外，它們還會(huì)影響整個(gè)集群的性能。

刷新頻率需要根據(jù)業(yè)務(wù)需要合理設(shè)置，尤其頻繁寫(xiě)入的業(yè)務(wù)場(chǎng)景。

7.8 啟動(dòng)慢查詢?nèi)罩?/span>

啟用慢查詢?nèi)罩居涗泴⒂兄谧R(shí)別哪些查詢慢，以及可以采取哪些措施來(lái)改進(jìn)它們，這對(duì)于通配符查詢特別有用。

推薦：

1. Elasticsearch高級(jí)調(diào)優(yōu)方法論之——根治慢查詢！

2. 為什么Elasticsearch查詢變得這么慢了？
   

7.9 增大ulimit大小

增加ulimit大小以允許最大文件數(shù)，這屬于非常常規(guī)的設(shè)置。

在 /etc/profile 下設(shè)置：

ulimit -n 65535

7.10 合理設(shè)置交互內(nèi)存

當(dāng)操作系統(tǒng)決定換出未使用的應(yīng)用程序內(nèi)存時(shí)，ElasticSearch 性能可能會(huì)受到影響。

通過(guò) elasticsearch.yml 下配置：

bootstrap.mlockall: true  

7.11 禁用通配符模糊匹配刪除索引

禁止通過(guò)通配符查詢刪除所有索引。

為確保某人不會(huì)對(duì)所有索引（* 或 _all）發(fā)出 DELETE 操作，設(shè)置如下：

PUT /_cluster/settings
{
  "persistent": {
    "action.destructive_requires_name": true
  }
}

此時(shí)如果我們?cè)偈褂猛ㄅ浞麆h除索引，舉例執(zhí)行如下操作：

DELETE join_*

會(huì)報(bào)錯(cuò)如下：

{
  "error" : {
    "root_cause" : [
      {
        "type" : "illegal_argument_exception",
        "reason" : "Wildcard expressions or all indices are not allowed"
      }
    ],
    "type" : "illegal_argument_exception",
    "reason" : "Wildcard expressions or all indices are not allowed"
  },
  "status" : 400
}

8、常用指標(biāo)監(jiān)視 API

8.1 集群健康狀態(tài) API

GET _cluster/health?pretty

8.2 索引信息 API

GET _cat/indices?pretty&v

8.3 節(jié)點(diǎn)狀態(tài) API

GET _nodes?pretty

8.4 主節(jié)點(diǎn)信息 API

GET _cat/master?pretty&v

8.5 分片分配、索引信息統(tǒng)計(jì) API

GET _stats?pretty

8.6 節(jié)點(diǎn)狀態(tài)信息統(tǒng)計(jì) API

統(tǒng)計(jì)節(jié)點(diǎn)的jvm，http，io統(tǒng)計(jì)信息。

GET _nodes/stats?pretty

大多數(shù)系統(tǒng)監(jiān)視工具（如kibana、cerebro 等）都支持 Elasticsearc h的指標(biāo)聚合。

建議使用此類工具持續(xù)監(jiān)控集群狀態(tài)信息。

9、小結(jié)

ElasticSearch 具有很好的默認(rèn)配置以供新手快速上手、入門(mén)。但是，一旦到了線上業(yè)務(wù)實(shí)戰(zhàn)環(huán)境，就必須花費(fèi)一些時(shí)間來(lái)調(diào)整設(shè)置以滿足實(shí)際業(yè)務(wù)功能要求以及性能指標(biāo)要求。

建議你參考本文建議并結(jié)合官方文檔修改相關(guān)配置，以使得集群整體部署最優(yōu)。

加微信：elastic6，一起探討部署最佳實(shí)踐。

參考

https://medium.com/@abhidrona/elasticsearch-deployment-best-practices-d6c1323b25d7

https://t.zsxq.com/UVbQbee