原文網(wǎng)址：ElasticSearch--優(yōu)化寫入速度的方法--修改配置_IT利刃出鞘的博客-CSDN博客

簡介

說明

? ? ? ? 本文介紹如何優(yōu)化ElasticSearch的寫入性能。

相關(guān)網(wǎng)址

ElasticSearch--寫入數(shù)據(jù)的流程(原理)_IT利刃出鞘的博客-CSDN博客

方案說明

? ? ? ? 下邊的方案，有的比較推薦改動，有的不推薦改動。不推薦的原因一般是得不償失，比如：數(shù)據(jù)容易丟失，查詢效率變低等。

tranlog flush（推薦）

改為異步刷新（推薦）

說明

????????從ES 2.x開始，translog默認的持久化策略為：每個請求都“flush”（寫入磁盤）。對應(yīng)配置項如下：

index.translog.durability: request

????????這是影響 ES 寫入速度的最大因素。但是這樣寫操作比較可靠。如果系統(tǒng)可以接受一定概率的數(shù)據(jù)丟失（例如：數(shù)據(jù)寫入主分片成功，尚未復(fù)制到副分片時，主機斷電。由于數(shù)據(jù)既沒有刷到Lucene，translog也沒有刷盤，恢復(fù)時translog中沒有這個數(shù)據(jù)，數(shù)據(jù)丟失），則調(diào)整translog持久化策略。

優(yōu)化方案

1.異步寫磁盤

index.translog.durability: async

減少刷盤次數(shù)（不推薦）

說明

????????每30分鐘或當translog達到一定大小(由index.translog.flush_threshold_size控制，默認512mb), ES會觸發(fā)一次flush操作，此時ES會先執(zhí)行refresh操作將buffer中的數(shù)據(jù)生成segment，然后調(diào)用lucene的commit方法將所有內(nèi)存中的segment 寫（fsync）到磁盤。

優(yōu)化方案

1.加大translog刷盤間隔時間。默認為5s，不可低于100ms。

index.translog.sync_interval: 120s

2.加大translog刷盤的最大觸發(fā)值。默認值為512MB。

index.translog.flush_threshold_size: 1024mb

設(shè)置為async表示translog的刷盤策略按sync_interval配置指定的時間周期進行。

增大indexing buffer（推薦）

說明

????????indexing buffer是為doc建立索引時使用的，當緩沖滿時會生成一個新的segment并觸發(fā)刷盤操作。這是除refresh_interval刷新索引外，另一個生成新segment的機會。

????????默認值不太夠用，對于大量寫入的場景也顯得有點小。

? ? ? ? 設(shè)置的這個index buffer大小，是所有的shard公用的，那些特別活躍的shard會更多的使用這個buffer。對于每個shard來說，最多給512mb，因為再大性能就沒什么提升了。

優(yōu)化方案

1.index_buffer_size（默認為10%，即：JVM堆大小的10%）

indices.memory.index_buffer_size=20%

2.min_index_buffer_size（默認為48m）

indices.memory.min_index_buffer_size=48MB

3.max_index_buffer_size（默認為無限制，一般無需改動）

indices.memory.min_index_buffer_size=xxx

增大線程池（推薦）

相關(guān)網(wǎng)址：ElasticSearch--線程池(ThreadPool)--使用/設(shè)置_IT利刃出鞘的博客-CSDN博客

說明

????????大量的寫入考慮使用bulk請求。

????????Bulk寫入索引的過程屬于計算密集型任務(wù)，應(yīng)該設(shè)置使用固定大小的線程池，來不及處理的任務(wù)放入隊列。線程池最大線程數(shù)量應(yīng)配置為CPU核心數(shù)+1（這也是默認設(shè)置），可以避免過多的上下文切換。隊列大小可以適當增加，但要嚴格控制大小，過大的隊列會導(dǎo)致較高的GC壓力，并可能導(dǎo)致FGC頻繁發(fā)生。

優(yōu)化方案

????????設(shè)置search、write、index、merge的隊列長度。線程池大小保持默認就好；一般修改隊列大小。

# Search pool
#thread_pool.search.size: 5
thread_pool.search.queue_size: 100

# Write pool
# thread_pool.bulk.size: 16
thread_pool.bulk.queue_size: 300

# Index pool
# thread_pool.index.size: 16
thread_pool.index.queue_size: 300

# 這個參數(shù)慎用！強制修改cpu核數(shù)，以突破寫線程數(shù)限制
# processors: 16

減小fielddata（推薦）

說明

????????在ES中，text類型的字段使用一種叫做fielddata的查詢時內(nèi)存數(shù)據(jù)結(jié)構(gòu)。當字段被排序，聚合或者通過腳本訪問時這種數(shù)據(jù)結(jié)構(gòu)會被創(chuàng)建。它是通過從磁盤讀取每個段的整個反向索引來構(gòu)建的，然后存存儲在java的堆內(nèi)存中。

　　fielddata默認是不開啟的。Fielddata可能會消耗大量的堆空間，尤其是在加載高基數(shù)文本字段時。一旦fielddata已加載到堆中，它將在該段的生命周期內(nèi)保留。此外，加載fielddata是一個昂貴的過程，可能會導(dǎo)致用戶遇到延遲命中。這就是默認情況下禁用fielddata的原因。如果嘗試對文本字段進行排序，聚合或腳本訪問，將看到以下異常：

　　“Fielddata is disabled on text fields by default. Set fielddata=true on [your_field_name] in order to load fielddata in memory by uninverting the inverted index. Note that this can however use significant memory.”

????????如果要對分詞的field執(zhí)行聚合操作，必須將fielddata設(shè)置為true：

POST /test_index/_mapping/test_type 
{
  "properties": {
    "test_field": {
      "type": "text",
      "fielddata": true
    }
  }
}

優(yōu)化方案

????????默認是沒有限制的，無限制可能導(dǎo)致頻繁的OOM，限制使用則有可能導(dǎo)致頻繁的驅(qū)逐（eict和relaod）、大量的IO性能損耗，內(nèi)存碎片，gc。

indices.fielddata.cache.size: 20%

也可以設(shè)置為絕對內(nèi)存比如16g等。超出限制，則會清除內(nèi)存已有的fielddata。
?

增大refresh interval（不推薦）

說明

????????默認情況下索引的refresh_interval為1秒，這意味著數(shù)據(jù)寫1秒后就可以被搜索到，進而滿足Elasticsearch的近實時查詢。

????????每次索引的refresh會產(chǎn)生一個新的Lucene段，會導(dǎo)致頻繁的segment merge行為，造成大量的磁盤io和內(nèi)存占用，影響效率。如果不需要這么高的實時性，應(yīng)該增大索引refresh周期。

優(yōu)化方案

1.增大索引refresh周期。（默認為1s）

index.refresh_interval: 30s

段合并（不推薦）

說明

????????segment merge操作對系統(tǒng)I/O和內(nèi)存占用都比較高，merge行為由Lucene控制。相關(guān)配置如下：

?index.merge.scheduler.max_thread_count (default Math.max(1, Math.min(4, Runtime.getRuntime().availableProcessors()/2)))

index.merge.policy.*

merge策略有三種：

1. tiered（默認策略）：分層合并策略，該策略將大小相似的段放在一起合并，當然段的數(shù)量會限制在每層允許的最大數(shù)量之中。
2. log_byte_size：字節(jié)大小對數(shù)合并策略，將創(chuàng)建由多個大小處于對數(shù)運算后大小在指定范圍索引組成的索引。
3. loc_doc：文檔數(shù)量對數(shù)合并策略，與log_byte_size策略類似，只是將以段的字節(jié)大小來計算的方式換成了文檔數(shù)量。

????????索引創(chuàng)建時合并策略就已確定，不能更改，但是可以動態(tài)更新策略參數(shù)。如果堆棧經(jīng)常有很多merge，則可以考慮適當增加index.merge.policy.segments_per_tier配置的值（該配置指定了每層分段的數(shù)量，取值越小則最終segment越少，因此需要merge的操作越多，可以考慮適當增加此值）。同時可以考慮適當降低index.merge.policy.max_merged_segment的值（指定了單個segment的最大容量）。

index.merge.policy.segments_per_tier (default 10，其應(yīng)該大于等于index.merge.policy.max_merge_at_once。)
index.merge.policy.max_merged_segment (default 5GB)

優(yōu)化方案

1.修改最大線程數(shù)

????????最大線程數(shù)max_thread_count的默認值是一個比較理想的值，如下：

Math.max（1, Math.min（4, Runtime.getRuntime（）.availableProcessors（） / 2））

1. 如果節(jié)點配置的cpu核數(shù)較高，merge占用的資源可能會偏高，影響集群的性能。
2. 如果只有一塊硬盤并且非 SSD，則應(yīng)該把它設(shè)置為1，因為在旋轉(zhuǎn)存儲介質(zhì)上并發(fā)寫，由于尋址的原因，只會降低寫入速度。
3. 如果Elasticsearch寫路徑配置多個磁盤，可以在磁盤數(shù)的范圍內(nèi)結(jié)合集群的負載取一個合適的值。

可以通過下面的命令調(diào)整某個index的merge過程的并發(fā)度：

index.merge.scheduler.max_thread_count:2

2.修改策略參數(shù)

????????索引創(chuàng)建時合并策略就已確定，不能更改，但可以動態(tài)更新策略參數(shù)。如果堆棧經(jīng)常有很多merge，則可以嘗試調(diào)整以下策略配置：

配置1：

index.merge.policy.segments_per_tier

????????該屬性指定了每層分段的數(shù)量，默認為10，取值越小則最終segment越少，因此想要merge的操作更多，可以考慮適當增加此值。其應(yīng)該大于等于index.merge.policy.max_merge_at_once（默認為10）。

配置2：

index.merge.policy.max_merged_segment

????????指定了單個segment的最大容量，默認為5GB，大于這個大小的segment，不用參與歸并（forcemerge 除外）。為了減少參與merge的segment的數(shù)量，減少磁盤IO以及內(nèi)存占用，可以考慮適當降低此值，此場景適用于按天或者時間段建index的場景，當index變?yōu)橹蛔x后使用forcemerge進行強制歸并，在提高檢索和Reindex效率的同時，減少內(nèi)存的占用。

節(jié)點探查時間（推薦）

官網(wǎng)網(wǎng)址：Zen Discovery | Elasticsearch Guide [6.6] | Elastic

說明

? ? ? ??大量寫入的場景，會占用大量的網(wǎng)絡(luò)帶寬，很可能使節(jié)點之間的心跳超時。并且默認的心跳間隔也相對過于頻繁（1s檢測一次）。

優(yōu)化方案

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

到了這里，關(guān)于ElasticSearch--優(yōu)化寫入速度的方法--修改配置的文章就介紹完了。如果您還想了解更多內(nèi)容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！