背景
優(yōu)化前,寫入速度平均3000條/s
,一遇到壓測(cè),寫入速度驟降,甚至es直接頻率gc、oom等;優(yōu)化后,寫入速度平均8000條/s
,遇到壓測(cè),能在壓測(cè)結(jié)束后30分鐘內(nèi)消化完數(shù)據(jù),各項(xiàng)指標(biāo)回歸正常。
生產(chǎn)配置
這里我先把自己優(yōu)化的結(jié)果貼出來,后面有參數(shù)的詳解:
elasticsearch.yml中增加如下設(shè)置
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
#這個(gè)參數(shù)慎用!強(qiáng)制修改cpu核數(shù),以突破寫線程數(shù)限制
#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
索引優(yōu)化配置:
PUT/_template/elk
{
"order":6,
"template":"logstash-*",#這里配置模板匹配的Index名稱
"settings":{
"number_of_replicas":0,#副本數(shù)為0,需要查詢性能高可以設(shè)置為1
"number_of_shards":6,#分片數(shù)為6,副本為1時(shí)可以設(shè)置成5
"refresh_interval":"30s",
"index.translog.durability":"async",
"index.translog.sync_interval":"30s"
}
}
優(yōu)化參數(shù)詳解
精細(xì)設(shè)置全文域: string類型字段默認(rèn)會(huì)分詞,不僅會(huì)額外占用資源,而且會(huì)影響創(chuàng)建索引的速度。所以,把不需要分詞的字段設(shè)置為not_analyzed
禁用_all字段: 對(duì)于日志和apm數(shù)據(jù),目前沒有場(chǎng)景會(huì)使用到
副本數(shù)量設(shè)置為0: 因?yàn)槲覀兡壳叭罩緮?shù)據(jù)和apm數(shù)據(jù)在es只保留最近7天的量,全量日志保存在hadoop,可以根據(jù)需要通過spark讀回到es – 況且副本數(shù)量是可以隨時(shí)修改的,區(qū)別分片數(shù)量
使用es自動(dòng)生成id: es對(duì)于自動(dòng)生成的id有優(yōu)化,避免了版本查找。因?yàn)槠渖傻膇d是唯一的
設(shè)置index.refresh_interval: 索引刷新間隔,默認(rèn)為1s。因?yàn)椴恍枰绱烁叩膶?shí)時(shí)性,我們修改為30s – 擴(kuò)展學(xué)習(xí):刷新索引到底要做什么事情
設(shè)置段合并的線程數(shù)量:
curl-XPUT'your-es-host:9200/nginx_log-2018-03-20/_settings'-d'{
"index.merge.scheduler.max_thread_count":1
}'
段合并的計(jì)算量龐大,而且還要吃掉大量磁盤I/O。合并在后臺(tái)定期操作,因?yàn)樗麄兛赡芤荛L(zhǎng)時(shí)間才能完成,尤其是比較大的段
機(jī)械磁盤在并發(fā)I/O支持方面比較差,所以我們需要降低每個(gè)索引并發(fā)訪問磁盤的線程數(shù)。這個(gè)設(shè)置允許max_thread_count + 2
個(gè)線程同時(shí)進(jìn)行磁盤操作,也就是設(shè)置為1允許三個(gè)線程
擴(kuò)展學(xué)習(xí):什么是段(segment)?如何合并段?為什么要合并段?(what、how、why)
1.設(shè)置異步刷盤事務(wù)日志文件:
"index.translog.durability":"async",
"index.translog.sync_interval":"30s"
對(duì)于日志場(chǎng)景,能夠接受部分?jǐn)?shù)據(jù)丟失。同時(shí)有全量可靠日志存儲(chǔ)在hadoop,丟失了也可以從hadoop恢復(fù)回來
2.elasticsearch.yml中增加如下設(shè)置:
indices.memory.index_buffer_size:20%
indices.memory.min_index_buffer_size:96mb
已經(jīng)索引好的文檔會(huì)先存放在內(nèi)存緩存中,等待被寫到到段(segment)中。緩存滿的時(shí)候會(huì)觸發(fā)段刷盤(吃i/o和cpu的操作)。默認(rèn)最小緩存大小為48m,不太夠,最大為堆內(nèi)存的10%。對(duì)于大量寫入的場(chǎng)景也顯得有點(diǎn)小。
擴(kuò)展學(xué)習(xí):數(shù)據(jù)寫入流程是怎么樣的(具體到如何構(gòu)建索引)?
1.設(shè)置index、merge、bulk、search的線程數(shù)和隊(duì)列數(shù)。例如以下elasticsearch.yml設(shè)置:
#Searchpool
thread_pool.search.size:5
thread_pool.search.queue_size:100
#這個(gè)參數(shù)慎用!強(qiáng)制修改cpu核數(shù),以突破寫線程數(shù)限制
#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.設(shè)置filedata cache大小,例如以下elasticsearch.yml配置:
indices.fielddata.cache.size:15%
filedata cache的使用場(chǎng)景是一些聚合操作(包括排序),構(gòu)建filedata cache是個(gè)相對(duì)昂貴的操作。所以盡量能讓他保留在內(nèi)存中
然后日志場(chǎng)景聚合操作比較少,絕大多數(shù)也集中在半夜,所以限制了這個(gè)值的大小,默認(rèn)是不受限制的,很可能占用過多的堆內(nèi)存
擴(kuò)展學(xué)習(xí):什么是filedata?構(gòu)建流程是怎樣的?為什么要用filedata?(what、how、why)
1.設(shè)置節(jié)點(diǎn)之間的故障檢測(cè)配置,例如以下elasticsearch.yml配置:
discovery.zen.fd.ping_timeout:120s
discovery.zen.fd.ping_retries:6
discovery.zen.fd.ping_interval:30s
大數(shù)量寫入的場(chǎng)景,會(huì)占用大量的網(wǎng)絡(luò)帶寬,很可能使節(jié)點(diǎn)之間的心跳超時(shí)。并且默認(rèn)的心跳間隔也相對(duì)過于頻繁(1s檢測(cè)一次)
此項(xiàng)配置將大大緩解節(jié)點(diǎn)間的超時(shí)問題
后記
這里僅僅是記錄對(duì)我們實(shí)際寫入有提升的一些配置項(xiàng),沒有針對(duì)個(gè)別配置項(xiàng)做深入研究。
擴(kuò)展學(xué)習(xí)后續(xù)填坑?;径甲裱╳hat、how、why)原則去學(xué)習(xí)。
-End-
審核編輯 :李倩
-
數(shù)據(jù)
+關(guān)注
關(guān)注
8文章
7128瀏覽量
89364 -
Elasticsearch
+關(guān)注
關(guān)注
0文章
30瀏覽量
2844
原文標(biāo)題:Elasticsearch 寫入優(yōu)化記錄,從3000到8000/s
文章出處:【微信號(hào):AndroidPush,微信公眾號(hào):Android編程精選】歡迎添加關(guān)注!文章轉(zhuǎn)載請(qǐng)注明出處。
發(fā)布評(píng)論請(qǐng)先 登錄
相關(guān)推薦
評(píng)論