Elasticsearch 寫入優化，從 3000 到 8000/s，讓你的 ES 飛起來。。。

背景

• 基于elasticsearch-5.6.0
• 機器配置：3個雲ecs節點，16G,4核，機械硬碟

優化前，寫入速度平均​

​3000條/s​

​​，一遇到壓測，寫入速度驟降，甚至es直接頻率gc、oom等；優化後，寫入速度平均​

​8000條/s​

​，遇到壓測，能在壓測結束後30分鐘内消化完資料，各項名額回歸正常。

生産配置

這裡我先把自己優化的結果貼出來，後面有參數的詳解：

elasticsearch.yml中增加如下設定

indices.memory.index_buffer_size: 20%
indices.memory.min_index_buffer_size: 96mb

# Search pool
thread_pool.search.size: 5
thread_pool.search.queue_size: 100
# 這個參數慎用！強制修改cpu核數，以突破寫線程數限制
# processors: 16
# Bulk 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

indices.fielddata.cache.size: 40%

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

索引優化配置：

PUT /_template/elk
{
      "order": 6,
      "template": "logstash-*",    #這裡配置模闆比對的Index名稱
      "settings": {
        "number_of_replicas" : 0,    #副本數為0,需要查詢性能高可以設定為1
        "number_of_shards" :   6,    #分片數為6, 副本為1時可以設定成5
         "refresh_interval": "30s",
         "index.translog.durability": "async",
        "index.translog.sync_interval": "30s"

      }
}      

優化參數詳解

精細設定全文域： string類型字段預設會分詞，不僅會額外占用資源，而且會影響建立索引的速度。是以，把不需要分詞的字段設定為​

​not_analyzed​

​

禁用_all字段: 對于日志和apm資料，目前沒有場景會使用到

副本數量設定為0: 因為我們目前日志資料和apm資料在es隻保留最近7天的量，全量日志儲存在hadoop，可以根據需要通過spark讀回到es – 況且副本數量是可以随時修改的，差別分片數量

使用es自動生成id： es對于自動生成的id有優化，避免了版本查找。因為其生成的id是唯一的

設定index.refresh_interval： 索引重新整理間隔，預設為1s。因為不需要如此高的實時性，我們修改為30s – 擴充學習：重新整理索引到底要做什麼事情

設定段合并的線程數量：

curl -XPUT 'your-es-host:9200/nginx_log-2018-03-20/_settings' -d '{ 
   "index.merge.scheduler.max_thread_count" : 1
}'      

段合并的計算量龐大，而且還要吃掉大量磁盤I/O。合并在背景定期操作，因為他們可能要很長時間才能完成，尤其是比較大的段

機械磁盤在并發I/O支援方面比較差，是以我們需要降低每個索引并發通路磁盤的線程數。這個設定允許​

​max_thread_count + 2​

​個線程同時進行磁盤操作，也就是設定為1允許三個線程

擴充學習：什麼是段(segment)？如何合并段？為什麼要合并段？（what、how、why）另外，ES 系列面試題和答案全部整理好了，微信搜尋Java技術棧，在背景發送：面試，可以線上閱讀。

1.設定異步刷盤事務日志檔案：

"index.translog.durability": "async",
"index.translog.sync_interval": "30s"      

對于日志場景，能夠接受部分資料丢失。同時有全量可靠日志存儲在hadoop，丢失了也可以從hadoop恢複回來

2.elasticsearch.yml中增加如下設定：

indices.memory.index_buffer_size: 20%
indices.memory.min_index_buffer_size: 96mb      

已經索引好的文檔會先存放在記憶體緩存中，等待被寫到到段(segment)中。緩存滿的時候會觸發段刷盤(吃i/o和cpu的操作)。預設最小緩存大小為48m，不太夠，最大為堆記憶體的10%。對于大量寫入的場景也顯得有點小。

擴充學習：資料寫入流程是怎麼樣的(具體到如何建構索引)？

1.設定index、merge、bulk、search的線程數和隊列數。例如以下elasticsearch.yml設定：

# Search pool
thread_pool.search.size: 5
thread_pool.search.queue_size: 100
# 這個參數慎用！強制修改cpu核數，以突破寫線程數限制
# processors: 16
# Bulk 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      

2.設定filedata cache大小，例如以下elasticsearch.yml配置：

indices.fielddata.cache.size: 15%      

filedata cache的使用場景是一些聚合操作(包括排序),建構filedata cache是個相對昂貴的操作。是以盡量能讓他保留在記憶體中

然後日志場景聚合操作比較少，絕大多數也集中在半夜，是以限制了這個值的大小，預設是不受限制的，很可能占用過多的堆記憶體

擴充學習：什麼是filedata？建構流程是怎樣的？為什麼要用filedata？（what、how、why）

1.設定節點之間的故障檢測配置，例如以下elasticsearch.yml配置：

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

大數量寫入的場景，會占用大量的網絡帶寬，很可能使節點之間的心跳逾時。并且預設的心跳間隔也相對過于頻繁（1s檢測一次）

此項配置将大大緩解節點間的逾時問題

後記

這裡僅僅是記錄對我們實際寫入有提升的一些配置項，沒有針對個别配置項做深入研究。

擴充學習後續填坑。基本都遵循（what、how、why）原則去學習。

覺得不錯，别忘了随手點贊+轉發哦！