在本文，我不是來告訴你 Elasticsearch 強大，快速并且幾乎可以正常運行。

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

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

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

基礎知識：集群，節點，索引和分片

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

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

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

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

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

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

總結一下，我們整理得到下圖：

更深入了解 Elasticsearch

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

Quorum

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

node.master: true

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

節點如何加入集群

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

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

初始狀態

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

節點 A 與 B 連接并交換信息

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

節點 C 連接并與 B 共享信息

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

段和段合并

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

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

在后臺，Lucene 進行持續的段合并，它不能更改段，但是可以使用兩個較小段的數據合并創建新的段。

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

消息路由

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

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

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

如何在生產環境運行 Elasticsearch?

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

大小

需要提出并隨后回答自己的第一個問題是關于大小調整。你需要多少規模的 ES 集群?

內存

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

堆

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

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

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

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

添加索引延遲，越低越好

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

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

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

文件緩存

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

CPU

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

磁盤

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

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

關于文件系統和 RAID 設置，我整理了以下幾點：

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

索引布局

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

分片

精簡版：

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

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

node_throughput * number_of_primary_shards  
節點吞吐量 * 主分片數量 

節點吞吐量 * 主分片數量

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

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

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

節點吞吐量 *(主分片數量 + 副本數)

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

大小

關于索引大小，我已經多次討論過。以下是我的經驗：

30G of heap = 140 shards maximum per node 
30G 堆內存 = 可以在一個節點最多啟動 140 個分片 

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

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

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

根據磁盤大小，可以很容易地計算出索引的大小：

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

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

段合并

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

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

集群布局

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

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

主節點可以非常小，一個 CPU 核，4G 的 RAM 已經足夠大多數集群使用。當然也需要關注實際使用情況，并進行相應調整。

監控

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

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

結論

本文花了我大約 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/