背景
優化前,寫入速度平均3000條/s
,一遇到壓測,寫入速度驟降,甚至es直接頻率gc、oom等;優化后,寫入速度平均8000條/s
,遇到壓測,能在壓測結束后30分鐘內消化完數據,各項指標回歸正常。
生產配置
這里我先把自己優化的結果貼出來,后面有參數的詳解:
elasticsearch.yml中增加如下設置
indices.memory.index_buffer_size:20%
indices.memory.min_index_buffer_size:96mb
#Searchpool
thread_pool.search.size:5
thread_pool.search.queue_size:100
#這個參數慎用!強制修改cpu核數,以突破寫線程數限制
#processors:16
#Bulkpool
#thread_pool.bulk.size:16
thread_pool.bulk.queue_size:300
#Indexpool
#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)
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設置:
#Searchpool
thread_pool.search.size:5
thread_pool.search.queue_size:100
#這個參數慎用!強制修改cpu核數,以突破寫線程數限制
#processors:16
#Bulkpool
thread_pool.bulk.size:16
thread_pool.bulk.queue_size:300
#Indexpool
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)原則去學習。
-End-
審核編輯 :李倩
-
數據
+關注
關注
8文章
6899瀏覽量
88844 -
Elasticsearch
+關注
關注
0文章
27瀏覽量
2823
原文標題:Elasticsearch 寫入優化記錄,從3000到8000/s
文章出處:【微信號:AndroidPush,微信公眾號:Android編程精選】歡迎添加關注!文章轉載請注明出處。
發布評論請先 登錄
相關推薦
評論