es高級優化

首先說明，此篇文章爲轉載，原文url:https://segmentfault.com/a/1190000017908981,我只是一個優秀的搬磚工，看到優秀的文章天然要和你們分享。

這是目前爲止我以爲最優秀的es調優之一，以前的優化也各有長處，可是寫這篇文章的大神是真正的10億數據調優的大神，幾乎涵蓋了我翻過的全部的文章，因此佩服。

「ELK」是 ElasticSearch、Logstash、Kibana 三門技術的簡稱。現在 ELK 技術棧在互聯網行業數據開發領域使用率愈來愈高，作過數據收集、數據開發、數據存儲的同窗相信對這個簡稱並不陌生，而ElasticSearch（如下簡稱 ES）則在 ELK 棧中佔着舉足輕重的地位。

前一段時間，我親身參與了一個 ES 集羣的調優，今天把我所瞭解與用到的調優方法與你們分享，若有錯誤，請你們包涵與指正。

系統層面的調優

系統層面的調優主要是內存的設定與避免交換內存。

ES 安裝後默認設置的堆內存是 1GB，這很明顯是不夠的，那麼接下來就會有一個問題出現：咱們要設置多少內存給 ES 呢？

其實這是要看咱們集羣節點的內存大小，還取決於咱們是否在服務器節點上仍是否要部署其餘服務。

若是內存相對很大，如 64G 及以上，而且咱們不在 ES 集羣上部署其餘服務，那麼我建議 ES 內存能夠設置爲 31G-32G，由於這裏有一個 32G 性能瓶頸問題，直白的說就是即便你給了 ES 集羣大於 32G 的內存，其性能也不必定會更加優良，甚至會不如設置爲 31G-32G 時候的性能。

以我調優的集羣爲例，我所調優的服務器節點內存爲 64G，服務器節點上也基本不跑其餘服務，因此我把 ES 集羣內存大小設置爲了 31G，以充分發揮集羣性能。

設置 ES 集羣內存的時候，還有一點就是確保堆內存最小值（Xms）與最大值（Xmx）的大小是相同的，防止程序在運行時改變堆內存大小，這是一個很耗系統資源的過程。

還有一點就是避免交換內存，能夠在配置文件中對內存進行鎖定，以免交換內存（也能夠在操做系統層面進行關閉內存交換）。對應的參數：

bootstrap.mlockall: true

分片與副本

分片 (shard)：ES 是一個分佈式的搜索引擎, 索引一般都會分解成不一樣部分, 分佈在不一樣節點的部分數據就是分片。ES 自動管理和組織分片, 並在必要的時候對分片數據進行再平衡分配, 因此用戶基本上不用擔憂分片的處理細節。建立索引時默認的分片數爲 5 個，而且一旦建立不能更改。

副本 (replica)：ES 默認建立一份副本，就是說在 5 個主分片的基礎上，每一個主分片都相應的有一個副本分片。額外的副本有利有弊，有副本能夠有更強的故障恢復能力，但也佔了相應副本倍數的磁盤空間。

那咱們在建立索引的時候，應該建立多少個分片與副本數呢？

對於副本數，比較好肯定，能夠根據咱們集羣節點的多少與咱們的存儲空間決定，咱們的集羣服務器多，而且有足夠大多存儲空間，能夠多設置副本數，通常是 1-3 個副本數，若是集羣服務器相對較少而且存儲空間沒有那麼寬鬆，則能夠只設定一份副本以保證容災（副本數能夠動態調整）。

對於分片數，是比較難肯定的。由於一個索引分片數一旦肯定，就不能更改，因此咱們在建立索引前，要充分的考慮到，之後咱們建立的索引所存儲的數據量，不然建立了不合適的分片數，會對咱們的性能形成很大的影響。

對於分片數的大小，業界一致認爲分片數的多少與內存掛鉤，認爲 1GB 堆內存對應 20-25 個分片，而一個分片的大小不要超過 50G，這樣的配置有助於集羣的健康。可是我我的認爲這樣的配置方法過於死板，我我的在調優 ES 集羣的過程當中，根據總數據量的大小，設定了相應的分片，保證每個分片的大小沒有超過 50G（大概在 40G 左右），可是相比以前的分片數查詢起來，效果並不明顯。以後又嘗試了增長分片數，發現分片數增多以後，查詢速度有了明顯的提高，每個分片的數據量控制在 10G 左右。

查詢大量小分片使得每一個分片處理數據速度更快了，那是否是分片數越多，咱們的查詢就越快，ES 性能就越好呢？其實也不是，由於在查詢過程當中，有一個分片合併的過程，若是分片數不斷的增長，合併的時間則會增長，並且隨着更多的任務須要按順序排隊和處理，更多的小分片不必定要比查詢較小數量的更大的分片更快。若是有多個併發查詢，則有不少小碎片也會下降查詢吞吐量。

若是如今你的場景是分片數不合適了，可是又不知道如何調整，那麼有一個好的解決方法就是按照時間建立索引，而後進行通配查詢。若是天天的數據量很大，則能夠按天建立索引，若是是一個月積累起來致使數據量很大，則能夠一個月建立一個索引。若是要對現有索引進行從新分片，則須要重建索引，我會在文章的最後總結重建索引的過程。

參數調優

下面我會介紹一些 ES 關鍵參數的調優。

有不少場景是，咱們的 ES 集羣佔用了多大的 cpu 使用率，該如何調節呢。cpu 使用率高，有多是寫入致使的，也有多是查詢致使的，那要怎麼查看呢？

能夠先經過 GET _nodes/{node}/hot_threads 查看線程棧，查看是哪一個線程佔用 cpu 高，若是是 elasticsearch[{node}][search][T#10] 則是查詢致使的，若是是 elasticsearch[{node}][bulk][T#1] 則是數據寫入致使的。
我在實際調優中，cpu 使用率很高，若是不是 SSD，建議把 index.merge.scheduler.max_thread_count: 1 索引 merge 最大線程數設置爲 1 個，該參數能夠有效調節寫入的性能。由於在存儲介質上併發寫，因爲尋址的緣由，寫入性能不會提高，只會下降。

還有幾個重要參數能夠進行設置，各位同窗能夠視本身的集羣狀況與數據狀況而定。

index.refresh_interval：這個參數的意思是數據寫入後幾秒能夠被搜索到，默認是 1s。每次索引的 refresh 會產生一個新的 lucene 段, 這會致使頻繁的合併行爲，若是業務需求對實時性要求沒那麼高，能夠將此參數調大，實際調優告訴我，該參數確實很給力，cpu 使用率直線降低。

indices.memory.index_buffer_size：若是咱們要進行很是重的高併發寫入操做，那麼最好將 indices.memory.index_buffer_size 調大一些，index buffer 的大小是全部的 shard 公用的，通常建議（看的大牛博客），對於每一個 shard 來講，最多給 512mb，由於再大性能就沒什麼提高了。ES 會將這個設置做爲每一個 shard 共享的 index buffer，那些特別活躍的 shard 會更多的使用這個 buffer。默認這個參數的值是 10%，也就是 jvm heap 的 10%。

translog：ES 爲了保證數據不丟失，每次 index、bulk、delete、update 完成的時候，必定會觸發刷新 translog 到磁盤上。在提升數據安全性的同時固然也下降了一點性能。若是你不在乎這點可能性，仍是但願性能優先，能夠設置以下參數：

"index.translog": {
            "sync_interval": "120s",     --sync間隔調高
            "durability": "async",       -– 異步更新
            "flush_threshold_size":"1g"  --log文件大小
        }

這樣設定的意思是開啓異步寫入磁盤，並設定寫入的時間間隔與大小，有助於寫入性能的提高。

還有一些超時參數的設置：

discovery.zen.ping_timeout 判斷 master 選舉過程當中，發現其餘 node 存活的超時設置
discovery.zen.fd.ping_interval 節點被 ping 的頻率，檢測節點是否存活
discovery.zen.fd.ping_timeout 節點存活響應的時間，默認爲 30s，若是網絡可能存在隱患，能夠適當調大
discovery.zen.fd.ping_retries ping 失敗/超時多少致使節點被視爲失敗，默認爲 3

其餘建議

還有一些零碎的優化建議喔。

插入索引自動生成 id：當寫入端使用特定的 id 將數據寫入 ES 時，ES 會檢查對應的索引下是否存在相同的 id，這個操做會隨着文檔數量的增長使消耗愈來愈大，因此若是業務上沒有硬性需求建議使用 ES 自動生成的 id，加快寫入速率。

避免稀疏索引：索引稀疏以後，會致使索引文件增大。ES 的 keyword，數組類型採用 doc_values 結構，即便字段是空值，每一個文檔也會佔用必定的空間，因此稀疏索引會形成磁盤增大，致使查詢和寫入效率下降。

個人調優

下面說一說個人調優：個人調優主要是重建索引，更改了現有索引的分片數量，通過不斷的測試，找到了一個最佳的分片數量，重建索引的時間是漫長的，在此期間，又對 ES 的寫入進行了相應的調優，使 cpu 使用率下降下來。附上個人調優參數。

index.merge.scheduler.max_thread_count:1 # 索引 merge 最大線程數
indices.memory.index_buffer_size:30%     # 內存
index.translog.durability:async # 這個能夠異步寫硬盤，增大寫的速度
index.translog.sync_interval:120s #translog 間隔時間
discovery.zen.ping_timeout:120s # 心跳超時時間
discovery.zen.fd.ping_interval:120s     # 節點檢測時間
discovery.zen.fd.ping_timeout:120s     #ping 超時時間
discovery.zen.fd.ping_retries:6     # 心跳重試次數
thread_pool.bulk.size:20 # 寫入線程個數 因爲咱們查詢線程都是在代碼裏設定好的，我這裏只調節了寫入的線程數
thread_pool.bulk.queue_size:1000 # 寫入線程隊列大小
index.refresh_interval:300s #index 刷新間隔

 

關於重建索引

在重建索引以前，首先要考慮一下重建索引的必要性，由於重建索引是很是耗時的。
ES 的 reindex api 不會去嘗試設置目標索引，不會複製源索引的設置，因此咱們應該在運行_reindex 操做以前設置目標索引，包括設置映射（mapping），分片，副本等。

第一步，和建立普通索引同樣建立新索引。當數據量很大的時候，須要設置刷新時間間隔，把 refresh_intervals 設置爲-1，即不刷新,number_of_replicas 副本數設置爲 0（由於副本數能夠動態調整，這樣有助於提高速度）。

{
    "settings": {

        "number_of_shards": "50",
        "number_of_replicas": "0",
        "index": {
            "refresh_interval": "-1"
        }
    }
    "mappings": {
    }
}

 

第二步，調用 reindex 接口，建議加上 wait_for_completion=false 的參數條件，這樣 reindex 將直接返回 taskId。

POST _reindex?wait_for_completion=false

{
  "source": {
    "index": "old_index",   //原有索引
    "size": 5000            //一個批次處理的數據量
  },
  "dest": {
    "index": "new_index",   //目標索引
  }
}

 

第三步，等待。能夠經過 GET _tasks?detailed=true&actions=*reindex 來查詢重建的進度。若是要取消 task 則調用_tasks/node_id:task_id/_cancel。

第四步，刪除舊索引，釋放磁盤空間。更多細節能夠查看 ES 官網的 reindex api。

那麼有的同窗可能會問，若是我此刻 ES 是實時寫入的，那咋辦呀？
這個時候，咱們就要重建索引的時候，在參數里加上上一次重建索引的時間戳，直白的說就是，好比咱們的數據是 100G，這時候咱們重建索引了，可是這個 100G 在增長，那麼咱們重建索引的時候，須要記錄好重建索引的時間戳，記錄時間戳的目的是下一次重建索引跑任務的時候不用所有重建，只須要在此時間戳以後的重建就能夠，如此迭代，直到新老索引數據量基本一致，把數據流向切換到新索引的名字。

 

POST /_reindex
{
    "conflicts": "proceed",          //意思是衝突以舊索引爲準，直接跳過沖突，不然會拋出異常，中止task
    "source": {
        "index": "old_index"         //舊索引
        "query": {
            "constant_score" : {
                "filter" : {
                    "range" : {
                        "data_update_time" : {
                            "gte" : 123456789   //reindex開始時刻前的毫秒時間戳
                            }
                        }
                    }
                }
            }
        },
    "dest": {
        "index": "new_index",       //新索引
        "version_type": "external"  //以舊索引的數據爲準
        }
}

以上就是我在 ES 調優上的一點總結，但願可以幫助到對 ES 性能有困惑的同窗們，謝謝你們。