在生產中執行Elasticsearch的深入指南 – TechNotes

banq發表於2020-02-24
Elasticsearch

在這篇文章中，我想分享我的經驗和技巧，以瞭解如何正確設定Elasticsearch並避免常見的陷阱。

基礎知識：叢集，節點，索引和分片
我想先解釋一些基本概念。本節將完全不介紹最佳實踐，而主要側重於解釋術語。大多數人可能會跳過此步驟。
Elasticsearch是用於執行Apache Lucene（基於Java的搜尋引擎）的分散式安裝的管理框架。Lucene實際上是儲存資料並進行所有索引和搜尋的地方。ES位於此之上，使您可以並行執行數千個Lucene例項。
ES的最高階別單元是群集。叢集是ES 節點 和索引的集合。

1.儘量使用堆，但堆大小不得超過30G
這是一個很多人都不知道的關於堆的秘密：堆中的每個物件都需要一個唯一的地址，即一個物件指標。該地址的長度是固定的，這意味著可以定址的物件數量是有限的。這很重要的簡短版本是，在某個時候，Java將開始使用壓縮的物件指標而不是未壓縮的物件指標。這意味著每個記憶體訪問都將涉及其他步驟，並且速度會慢得多。您100％不想超過此閾值（大約32G）。
長話短說：如果感到幸運，請使用29G的RAM或30的RAM，請使用XFS，並儘可能使用hardwareprefetch和llc-prefetch。

2.FS快取
大多數人在Linux上執行Elasticsearch，Linux使用RAM作為檔案系統快取。常見的建議是將64G用於ES伺服器，這樣的想法是一半快取，一半堆。我尚未測試FS快取。但是，不難看出，大型ES群集（如用於日誌記錄）可以從擁有大型FS快取中受益匪淺。如果您所有的索引都適合放入堆，則不會那麼多。

3. CPU
如果您進行大量索引編制，則與僅執行日誌記錄相比，您需要更多，更快的CPU。對於日誌記錄，我發現8個核心綽綽有餘。

4.磁碟
首先，如果索引適合RAM，則磁碟僅在節點冷啟動時才重要。其次，實際可以儲存的資料量取決於索引布局。每個分片都是Lucene例項，它們都有記憶體需求。這意味著您可以在堆中容納最大數量的分片。
通常，您可以將所有資料磁碟放入RAID0。您應該在Elasticsearch級別進行復制，因此丟失節點無關緊要。請勿將LVM與多個磁碟一起使用，因為LVM一次只能寫入一個磁碟，根本就不會給您帶來多個磁碟的好處。
關於檔案系統和RAID設定，我發現以下內容：

  • Scheduler：cfq和截止日期優於noop。如果您有nvme，但我還沒有測試過，Kyber可能會很好
  • QueueDepth：儘可能高
  • Readahead：需要
  • Raid chunk size：無影響
  • FS塊大小：無影響
  • FS型別：XFS> ext4

5.分片
精簡版：

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

公式：node_throughput*number_of_primary_shards
如果要最佳化搜尋效能，可以透過以下公式給出搜尋效能：
node_throughput*(number_of_primary_shards + number_of_replicas)
對於搜尋，主分片和副本分片基本上是相同的。因此，如果您想提高搜尋效能，只需增加副本數即可。

6. 索引大小
30G堆=每個節點最多140個分片
使用超過140個分片，會使Elasticsearch程式崩潰並出現記憶體不足錯誤。這是因為每個分片都是Lucene例項，並且每個例項都需要一定數量的記憶體。這意味著每個節點可以有多少個分片。
如果您有節點數量，分片數量和索引大小，則可以計算容納多少個索引：
number_of_indices = (140 * number_of_nodes) / (number_of_primary_shards * replication_factor)
根據您的磁碟大小，您可以輕鬆地計算出索引的大小：
index_size = (number_of_nodes * disk_size) / number_of_indices
但是，請記住，較大的索引也較慢。對於日誌記錄來說，一定程度是可以的，但是對於真正搜尋繁重的應用程式，您應該根據所擁有的RAM數量來增加大小。

7. 段合併
請記住，每個段都是檔案系統上的實際檔案。更多的細分=更多的閱讀開銷。基本上，對於每個搜尋查詢，它都轉到索引中的所有分片，再從那裡到分片中的所有段。擁有許多段會極大地增加群集的讀取IOPS，直至無法使用為止。因此，最好將段數保持在儘可能低的水平。
有一個force_merge API，它允許您將段合併到一定數量，例如1。如果進行索引輪換，例如，因為您使用Elasticsearch進行日誌記錄，則在不使用群集時進行常規強制合併是一個好主意。強制合併會佔用大量資源，並且會大大降低群集的速度。因此，最好不要讓Graylog為您做到這一點，但是當叢集使用較少時，您可以自己做。如果您有很多索引，則肯定要這樣做。否則，您的群集將緩慢爬行到停止狀態。

8.叢集佈局
對於除最小設定以外的所有內容，最好使用專用的符合主機資格的節點。主要原因是您應始終具有2n + 1個符合主機資格的節點以確保仲裁。但是對於資料節點，您只希望能夠隨時新增一個新節點，而不必擔心此要求。另外，您也不希望資料節點上的高負載影響您的主節點。
最後，主節點是種子節點的理想候選者。請記住，種子節點是您在Elasticsearch中執行節點發現的最簡單方法。
主節點可能很小，一個CPU核甚至4GRAM足以滿足大多數群集的需求。與往常一樣，關注實際使用情況並進行相應調整。

9.監控方式
我喜歡監視，也喜歡監視Elasticsearch。ES為您提供了大量的指標，並且以JSON的形式為您提供所有指標，這使得傳遞給監視工具非常容易。以下是一些有用的監視內容：

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

更多點選標題見原文。


 

相關文章