背景 基於elasticsearch-5.6.0 機器配置：3個雲ecs節點，16G,4核，機械硬碟 優化前，寫入速度平均3000條/s，一遇到壓測，寫入速度驟降，甚至es直接頻率gc、oom等；優化後，寫入速度平均8000條/s，遇到壓測，能在壓測結束後30分鐘內消化完數據，各項指標回歸正常。 生 ...
背景
- 基於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）原則去學習。
版權聲明：本文為CSDN博主「無影V隨風」的原創文章，遵循CC 4.0 BY-SA版權協議，轉載請附上原文出處鏈接及本聲明。原文鏈接：https://blog.csdn.net/wmj2004/article/details/80804411
近期熱文推薦：
1.1,000+ 道 Java面試題及答案整理(2022最新版)
4.別再寫滿屏的爆爆爆炸類了，試試裝飾器模式，這才是優雅的方式！！
覺得不錯，別忘了隨手點贊+轉發哦！
