背景

• 基於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開發手冊（嵩山版）》最新發布，速速下載！

覺得不錯，別忘了隨手點贊+轉發哦！