在本文，我不是來告訴你 Elasticsearch 強大，快速并且?guī)缀蹩梢哉＿\行。

在本文，我也是來告訴你 Elasticsearch 可能是不透明的，讓人困擾，并且似乎無緣無故地出問題。在這篇

在本文，我想分享我的經(jīng)驗和技巧，了解如何正確配置 Elasticsearch 并避免常見的陷阱。

我寫文章目的也不是為了贏利，所以我會將全部內(nèi)容放到這一篇文章中，而不是將它分解成一系列。你可以隨意跳過不感興趣的章節(jié)。

基礎知識：集群，節(jié)點，索引和分片

如果你是 Elasticsearch(ES)新手，我想先解釋一些基本概念。本節(jié)完全不涉及最佳實踐，主要側(cè)重于解釋術(shù)語。大多數(shù)人可以直接跳過本節(jié)。

Elasticsearch 是用于運行 Apache Lucene(基于 Java 的搜索引擎)分布式管理框架。Lucene 是實際保存數(shù)據(jù)并進行索引和搜索的地方。ES 位于它之上，讓你可以并行運行數(shù)千個 Lucene 實例。

ES 的最高級別單元是集群(cluster)。集群是 ES 節(jié)點 和索引的集合。

節(jié)點 (Node) 是 ES 的實例。它可以是單個服務器，也可以是服務器上運行的 一個 ES 進程。服務器和節(jié)點不同，一個 VM 或物理服務器可以包含許多 ES 進程，每個 ES 進程是一個節(jié)點。節(jié)點只可以加入一個集群。節(jié)點有不同類型(type)，其中最值得關(guān)注的兩個類型是數(shù)據(jù)節(jié)點(data node)和主候選節(jié)點( Master-Eligible node)。一個節(jié)點可以同時具有多種類型。數(shù)據(jù)節(jié)點運行所有數(shù)據(jù)操作，即存儲、索引和檢索數(shù)據(jù)。主候選節(jié)點具有投票 master 的權(quán)限，用于管理集群和索引。

索引(Index)是對數(shù)據(jù)的高級抽象，索引本身不保存數(shù)據(jù)，它們只是實際存儲數(shù)據(jù)的另一種抽象。對數(shù)據(jù)執(zhí)行的任何操作(例如插入，刪除，建立索引和搜索)都會對索引產(chǎn)生影響。索引可以完全屬于一個集群，并且由分片( shard) 組成。

分片(Shard)是 Apache Lucene 的實例。一個分片可以容納許多文檔。分片是數(shù)據(jù)存儲，索引和搜索的實際對象。分片只屬于一個節(jié)點和索引。分片有兩種類型：primary 和 replica，它們基本上是完全相同的，擁有相同的數(shù)據(jù)，并且搜索并行運行在所有分片。在擁有相同數(shù)據(jù)的所有分片中，其中一個屬于 primary。這是唯一可以接受索引請求的分片。如果節(jié)點中的主分片掛了，副本將接管并成為主分片。然后，ES 將創(chuàng)建一個新的副本并復制數(shù)據(jù)。

總結(jié)一下，我們整理得到下圖：

更深入了解 Elasticsearch

如果你想運行一個系統(tǒng)，相信你需要了解該系統(tǒng)。在本節(jié)中，我將解釋 Elasticsearch 的各個部分，如果想在生產(chǎn)中進行管理，我相信你需要理解它。本節(jié)也不牽涉到具體建議，后文會介紹。本節(jié)目的只是為了介紹必要的背景。

Quorum

理解 Elasticsearch 是一個(有缺陷的)選舉體系非常重要。節(jié)點投票決定誰應該管理它們，即主節(jié)點。主節(jié)點運行大量集群管理進程，并且在許多事務方面擁有最終決策權(quán)。ES 選舉是有缺陷的，是因為只有一小部分節(jié)點，即主候選(master-eligible)節(jié)點才具有投票權(quán)。主候選節(jié)點是通過以下配置啟用：

node.master: true

在集群啟動或主節(jié)點離開群集時，所有符合主選舉條件的節(jié)點都會開始選舉新的主節(jié)點。為此，你需要具有 2n + 1 個主候選節(jié)點。否則，可能會出現(xiàn)腦裂情況，比如同時兩個節(jié)點獲得 50% 的選票，將會導致兩個分區(qū)之一中的所有數(shù)據(jù)丟失。為了不發(fā)生這種情況。你需要 2n + 1 個符合主候選的節(jié)點。

節(jié)點如何加入集群

當 ES 節(jié)點啟動時，它在廣闊世界中獨自存在。它怎么知道它屬于哪個集群?有不同的方法可以完成此操作，如今大多使用種子主機(Seed Host)的方法來實現(xiàn)。

基本上，Elasticsearch 節(jié)點會不斷地就他們所見過的所有其他節(jié)點進行通訊。因此一個節(jié)點最初只需要了解幾個其他節(jié)點即可了解整個集群。讓我們來看一個三節(jié)點集群的示例：

初始狀態(tài)

最初，節(jié)點 A 和 C 只知道 B。B 是種子主機。種子主機要么以配置文件的形式提供給 ES，要么直接放入 elasticsearch.yml 中。

節(jié)點 A 與 B 連接并交換信息

一旦節(jié)點 A 連接到 B，B 就知道 A 的存在。對于 A 而言，沒有任何變化。

節(jié)點 C 連接并與 B 共享信息

現(xiàn)在，C 連上來。一旦發(fā)生這種情況，B 就會告訴 C 有 A 的存在。C 和 B 現(xiàn)在知道群集中的所有節(jié)點。一旦 A 重新連接到 B，它也將了解 C 的存在。

段和段合并

上面我說過數(shù)據(jù)存儲分片中，這只是部分正確。最終數(shù)據(jù)是以文件的形式存儲在文件系統(tǒng)中。在 Lucene 和 Elasticsearch 中，這些文件稱為段(Segment)。一個分片將具有一到數(shù)千個段。

同樣，段是實際的真實文件，你可以在 Elasticsearch 安裝的 data 目錄中查看它。這意味著使用段存在開銷。如果要查看段，則必須找到文件并打開它。這意味著需要打開許多文件，并且將會有很多開銷。Lucene 中的段是不可變的，這是個問題。它們只能寫一次，然后就不能改了。反過來，這意味著你放入 ES 中的每個文檔都將創(chuàng)建一個僅包含這個文檔的段。顯然，一個擁有十億個文檔的集群具有十億個段，這意味著文件系統(tǒng)上確實有十億個文件，這樣理解對嗎?非也。

在后臺，Lucene 進行持續(xù)的段合并，它不能更改段，但是可以使用兩個較小段的數(shù)據(jù)合并創(chuàng)建新的段。

這樣，lucene 會不斷嘗試使段數(shù)(文件數(shù)，即開銷)保持較小。你也可以使用強制合并。

消息路由

在 Elasticsearch 中，你可以對集群中的任何節(jié)點運行任何命令，返回結(jié)果是相同的。有趣的是，文檔最終將只存在于一個主分片及其副本中，而 ES 不知道它在哪里。沒有一個映射來記錄某個文檔位于哪個分片中。

當執(zhí)行搜索時，獲取請求的 ES 節(jié)點會將其廣播到索引中的所有分片。即主分片及所有副本。這些分片然后會在包含該文檔的所有段中進行查找。

當執(zhí)行插入時，ES 節(jié)點將隨機選擇一個主分片并將文檔放在其中。然后將其寫入該主分片及其所有副本。

如何在生產(chǎn)環(huán)境運行 Elasticsearch?

本節(jié)是實踐部分。我前面提到，我管理 ES 的主要目的是為了記錄日志，本文將盡力避免這種傾向的影響，但有可能會失敗。

大小

需要提出并隨后回答自己的第一個問題是關(guān)于大小調(diào)整。你需要多少規(guī)模的 ES 集群?

內(nèi)存

我首先說的是 RAM，因為 RAM 將限制所有其他資源。

堆

ES 用 Java 編寫，Java 使用堆，你可以將其視為 Java 保留的內(nèi)存。如果將所有堆的重要因素都列出，會使這個文檔的大小增加三倍，所以我將介紹最重要的部分，即堆大小。

盡量使用更多內(nèi)存，但堆大小不得超過 30G。

有一個很多人都不知道的關(guān)于堆的秘密：堆中的每個對象都需要一個唯一的地址，即一個對象指針。該地址的長度是固定的，這意味著可以尋址的對象數(shù)量是有限的。簡單一點來描述就是，超出某個范圍時，Java 將開始使用壓縮的對象指針而不是未壓縮的對象指針。這意味著每個內(nèi)存訪問都將涉及其他步驟，這會嚴重拖慢速度。因此你 100% 不需要設置超過此閾值(大約 32G)。

我曾經(jīng)整整一個星期都呆在一個黑暗的房間里，沒做別的，只是使用 esrally 基準化測試 Elasticsearch 在不同文件系統(tǒng)、堆大小、文件和 BIOS 設置組合。長話短說，下面就是關(guān)于堆大小如何設置的內(nèi)容：

添加索引延遲，越低越好

命名約定為 fs_heapsize_biosflags。如你所見，從 32G 的堆大小開始，性能突然開始變差。吞吐量也同樣情況：

索引附加中值吞吐量。越高越好。

長話短說：如果想幸運一點，請使用 29G 或 30G 的 RAM，并使用 XFS，并盡可能啟用 hardwareprefetch 和 llc-prefetch。

文件緩存

大多數(shù)人在 Linux 上運行 Elasticsearch，Linux 使用內(nèi)存作為文件系統(tǒng)緩存。常見的建議是 ES 服務器使用 64G 內(nèi)存，這樣的想法是一半用于緩存，一半用于堆。我尚未測試過文件緩存。但是不難看出，大型 ES 集群(如用于日志記錄)可以從配置大文件緩存中受益匪淺。如果你所有的索引都適合放入內(nèi)存堆，則不會那么多好處。

CPU

這取決于對集群執(zhí)行的操作。如果進行大量索引，與僅執(zhí)行日志記錄相比，你需要更多更快的 CPU。對于日志記錄，我發(fā)現(xiàn) 8 個 CPU 核綽綽有余，但是發(fā)現(xiàn)很多人使用更大的配置，但是對他的使用場景并沒有什么好處。

磁盤

這塊也沒有想像那么直接。首先，如果索引能放入 RAM，則磁盤僅在節(jié)點冷啟動時才重要。其次，實際可以存儲的數(shù)據(jù)量取決于索引布局。每個分片都是一個 Lucene 實例，它們都有內(nèi)存需求。這意味著你可以在堆中容納最大數(shù)量分片是有限的。我將在索引布局部分中詳細討論這一點。

通常，你可以將所有數(shù)據(jù)磁盤放入 RAID0。你需要在 Elasticsearch 級別進行復制，因此丟失一個節(jié)點無關(guān)緊要。請勿將 LVM 與多個磁盤一起使用，因為 LVM 一次只能寫入一個磁盤，根本就不會帶來多個磁盤的好處。

關(guān)于文件系統(tǒng)和 RAID 設置，我整理了以下幾點：

• Scheduler：cfq 和 deadline 優(yōu)于 noop。如果你有 nvme，Kyber 可能會很好，但我還沒有測試過
• QueueDepth：盡可能高
• 預讀：請打開
• Raid chunk size：無影響
• FS 塊大?。簾o影響
• FS 類型：XFS > ext4

索引布局

這在很大程度上取決于你的用例。我只能從日志場景(尤其是使用 Graylog)討論一下。

分片

精簡版：

• 對于寫入繁重的工作負載，主分片 = 節(jié)點數(shù)
• 對于讀取繁重的工作負載，主分片 * 副本數(shù) = 節(jié)點數(shù)
• 更多副本 = 更高的搜索性能

可以通過以下公式給出最大寫入性能：

node_throughput * number_of_primary_shards  
節(jié)點吞吐量 * 主分片數(shù)量 

節(jié)點吞吐量 * 主分片數(shù)量

原因很簡單：如果只有一個主分片，那么寫入速度只類似于單節(jié)點，因為一個分片只能位于一個節(jié)點上。如果確實想優(yōu)化寫入性能，則應確保每個節(jié)點上只有一個分片(主節(jié)點或副本)，因為在此情況下副本可以獲得與主節(jié)點相同的寫入速度，并且寫入很大程度上取決于磁盤 IO。注意：如果有很多索引，那么上述的策略可能有問題，性能瓶頸可能是其他原因。

如果要優(yōu)化搜索性能，可以通過以下公式給出：

node_throughput * (number_of_primary_shards + number_of_replicas)  
節(jié)點吞吐量 *（主分片數(shù)量 + 副本數(shù)） 

節(jié)點吞吐量 *(主分片數(shù)量 + 副本數(shù))

對于搜索，主分片和副本基本相同。因此，如果想提高搜索性能，只需增加副本的數(shù)量。

大小

關(guān)于索引大小，我已經(jīng)多次討論過。以下是我的經(jīng)驗：

30G of heap = 140 shards maximum per node 
30G 堆內(nèi)存 = 可以在一個節(jié)點最多啟動 140 個分片 

使用 140 個以上的分片，Elasticsearch 就會進程崩潰并出現(xiàn)內(nèi)存不足錯誤。這是因為每個分片都是 Lucene 實例，并且每個實例都需要一定數(shù)量的內(nèi)存。這意味著每個節(jié)點可以擁有的分片數(shù)量是有限制的。

如果你有大量節(jié)點，分片和索引大小，則可以容納多少個索引可以由以下公式計算：

number_of_indices = (140 * number_of_nodes) / (number_of_primary_shards * replication_factor)  
索引數(shù) = (140*節(jié)點數(shù))/（主分片數(shù) * 復制因子） 

根據(jù)磁盤大小，可以很容易地計算出索引的大?。?/p>

index_size = (number_of_nodes * disk_size) / number_of_indices 
索引大小 = （節(jié)點數(shù)量 * 磁盤大小）/ 索引數(shù)量 

然而索引越大搜索越慢。對于日志記錄來說，慢一點問題不大，但是對于真正的搜索量大的應用程序，應該根據(jù) RAM 大小來調(diào)整索引大小。

段合并

每個段都是文件系統(tǒng)中的一個實際文件，更多的段意味著更大的讀取開銷。基本上，對于每個搜索查詢，它都會轉(zhuǎn)到索引中的所有分片，再轉(zhuǎn)到分片中的所有段。多個段極大地增加集群讀取 IOPS，直到它變得不可用。因此，需要盡可能減少段的數(shù)量。

force_merge API 允許你將段合并到某個數(shù)量，比如 1。如果你執(zhí)行索引滾動(例如使用 Elasticsearch 做日志記錄)，那么在集群未使用時執(zhí)行常規(guī)強制合并是一個好建議。強制合并會占用大量資源，并且會顯著降低集群的運行速度。因此，最好不要讓 Graylog 幫你來做，而是選擇在較少使用集群時間自己完成。如果你有很多索引的話，你必須定期執(zhí)行段合并。否則，集群運行速度將會非常慢并最終掛掉。

集群布局

對于除最小設置外的所有設置，最好使用專用的候選主節(jié)點。主要原因是確保始終有 2n + 1 個候選主節(jié)點來確保仲裁。但是對于數(shù)據(jù)節(jié)點，可以在任何時候添加新節(jié)點，而不必擔心這個需求。另外，我們不希望數(shù)據(jù)節(jié)點上的高負載影響主節(jié)點。

最后，主節(jié)點是種子節(jié)點的理想候選節(jié)點。請記住，種子節(jié)點是在 Elasticsearch 中進行節(jié)點發(fā)現(xiàn)的最簡單方法。由于主節(jié)點很少更改，因此它是最佳選擇，因為它很可能已經(jīng)知道集群中的所有其他節(jié)點。

主節(jié)點可以非常小，一個 CPU 核，4G 的 RAM 已經(jīng)足夠大多數(shù)集群使用。當然也需要關(guān)注實際使用情況，并進行相應調(diào)整。

監(jiān)控

ES 為你提供了大量的指標，并且以 JSON 的形式提供所有指標，這使得傳遞給監(jiān)控工具非常容易。以下是一些有用的監(jiān)控指標：

• 段數(shù)
• 堆使用
• 堆 GC 時間
• 平均 搜索，索引，合并時間
• IOPS
• 磁盤利用率

結(jié)論

本文花了我大約 5 個小時，包含了我對 ES 的所有了解，希望能讓你碰到問題的時候不那么頭疼。

資源

• https://www.elastic.co/guide/zh-CN/elasticsearch/reference/current/modules-node.html
• https://www.elastic.co/guide/en/elasticsearch/reference/master/modules-discovery-quorums .html
• https://github.com/elastic/rally
• https://tech.ebayinc.com/engineering/elasticsearch-performance-tuning-practice-at-ebay/