Elasticsearch 寫入優(yōu)化，從 3000 到 8000/s，讓你的 ES 飛起來！

點擊關注公眾號，Java干貨及時送達

背景

• 基于elasticsearch-5.6.0
• 機器配置：3個云ecs節(jié)點，16G,4核，機械硬盤

優(yōu)化前，寫入速度平均3000條/s，一遇到壓測，寫入速度驟降，甚至es直接頻率gc、oom等；優(yōu)化后，寫入速度平均8000條/s，遇到壓測，能在壓測結束后30分鐘內消化完數(shù)據(jù)，各項指標回歸正常。

生產配置

這里我先把自己優(yōu)化的結果貼出來，后面有參數(shù)的詳解：

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
#?這個參數(shù)慎用！強制修改cpu核數(shù)，以突破寫線程數(shù)限制
#?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

索引優(yōu)化配置：

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

??????}
}

優(yōu)化參數(shù)詳解

精細設置全文域： string類型字段默認會分詞，不僅會額外占用資源，而且會影響創(chuàng)建索引的速度。所以，把不需要分詞的字段設置為not_analyzed

禁用_all字段: 對于日志和apm數(shù)據(jù)，目前沒有場景會使用到

副本數(shù)量設置為0: 因為我們目前日志數(shù)據(jù)和apm數(shù)據(jù)在es只保留最近7天的量，全量日志保存在hadoop，可以根據(jù)需要通過spark讀回到es – 況且副本數(shù)量是可以隨時修改的，區(qū)別分片數(shù)量

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

設置index.refresh_interval： 索引刷新間隔，默認為1s。因為不需要如此高的實時性，我們修改為30s – 擴展學習：刷新索引到底要做什么事情

設置段合并的線程數(shù)量：

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

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

機械磁盤在并發(fā)I/O支持方面比較差，所以我們需要降低每個索引并發(fā)訪問磁盤的線程數(shù)。這個設置允許max_thread_count + 2個線程同時進行磁盤操作，也就是設置為1允許三個線程

擴展學習：什么是段(segment)？如何合并段？為什么要合并段？（what、how、why）最新面試題整理好了，大家可以在Java面試庫小程序在線刷題。

1.設置異步刷盤事務日志文件：

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

對于日志場景，能夠接受部分數(shù)據(jù)丟失。同時有全量可靠日志存儲在hadoop，丟失了也可以從hadoop恢復回來

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

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

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

擴展學習：數(shù)據(jù)寫入流程是怎么樣的(具體到如何構建索引)？

1.設置index、merge、bulk、search的線程數(shù)和隊列數(shù)。例如以下elasticsearch.yml設置：

#?Search?pool
thread_pool.search.size:?5
thread_pool.search.queue_size:?100
#?這個參數(shù)慎用！強制修改cpu核數(shù)，以突破寫線程數(shù)限制
#?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是個相對昂貴的操作。所以盡量能讓他保留在內存中

然后日志場景聚合操作比較少，絕大多數(shù)也集中在半夜，所以限制了這個值的大小，默認是不受限制的，很可能占用過多的堆內存

擴展學習：什么是filedata？構建流程是怎樣的？為什么要用filedata？（what、how、why）最新面試題整理好了，大家可以在Java面試庫小程序在線刷題。

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

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

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

此項配置將大大緩解節(jié)點間的超時問題。

后記

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

擴展學習后續(xù)填坑?；径甲裱╳hat、how、why）原則去學習。

版權聲明：本文為CSDN博主「無影V隨風」的原創(chuàng)文章，遵循CC 4.0 BY-SA版權協(xié)議，轉載請附上原文出處鏈接及本聲明。原文鏈接：https://blog.csdn.net/wmj2004/article/details/80804411