背景
- 基于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最新版)
2.勁爆！Java 協程要來了，，，
3.Spring Boot 2.x 教程，太全了！
4.別再寫滿屏的爆爆爆炸類了，試試裝飾器模式，這才是優雅的方式！！
5.《Java開發手冊（嵩山版）》最新發布，速速下載！
覺得不錯，別忘了隨手點贊+轉發哦！
轉載請註明出處，本文鏈接：https://www.uj5u.com/houduan/473438.html
標籤：其他
上一篇：二刷SSM-Day1
下一篇：哈工大軟體構造（前置篇）