從10秒到2秒！ElasticSearch性能調(diào)優(yōu)實踐
“ELK”是 ElasticSearch、Logstash、Kibana 三門技術(shù)的簡稱，如今 ELK 技術(shù)棧在互聯(lián)網(wǎng)行業(yè)數(shù)據(jù)開發(fā)領(lǐng)域使用率越來越高。
做過數(shù)據(jù)收集、數(shù)據(jù)開發(fā)、數(shù)據(jù)存儲的同學相信對這個簡稱并不陌生，而 ElasticSearch(以下簡稱 ES)則在 ELK 棧中占著舉足輕重的地位。
前一段時間，我親身參與了一個 ES 集群的調(diào)優(yōu)，今天把我所了解與用到的調(diào)優(yōu)方法與大家分享，如有錯誤，請大家包涵與指正。
系統(tǒng)層面的調(diào)優(yōu)
系統(tǒng)層面的調(diào)優(yōu)主要是內(nèi)存的設(shè)定與避免交換內(nèi)存。ES 安裝后默認設(shè)置的堆內(nèi)存是 1GB，這很明顯是不夠的，那么接下來就會有一個問題出現(xiàn)：我們要設(shè)置多少內(nèi)存給 ES 呢?
其實這是要看我們集群節(jié)點的內(nèi)存大小，還取決于我們是否在服務器節(jié)點上還要部署其他服務。
如果內(nèi)存相對很大，如 64G 及以上，并且我們不在 ES 集群上部署其他服務，那么我建議 ES 內(nèi)存可以設(shè)置為 31G-32G，因為這里有一個 32G 性能瓶頸問題。
直白的說就是即使你給了 ES 集群大于 32G 的內(nèi)存，其性能也不一定會更加優(yōu)良，甚至會不如設(shè)置為 31G-32G 時候的性能。
以我調(diào)優(yōu)的集群為例，我所調(diào)優(yōu)的服務器節(jié)點內(nèi)存為 64G，服務器節(jié)點上也基本不跑其他服務，所以我把 ES 集群內(nèi)存大小設(shè)置為了 31G，以充分發(fā)揮集群性能。
設(shè)置 ES 集群內(nèi)存的時候，還有一點就是確保堆內(nèi)存最小值(Xms)與***值(Xmx)的大小是相同的，防止程序在運行時改變堆內(nèi)存大小，這是一個很耗系統(tǒng)資源的過程。
還有一點就是避免交換內(nèi)存，可以在配置文件中對內(nèi)存進行鎖定，以避免交換內(nèi)存(也可以在操作系統(tǒng)層面進行關(guān)閉內(nèi)存交換)。
對應的參數(shù)：
- bootstrap.mlockall: true
分片與副本
分片 (shard)
ES 是一個分布式的搜索引擎, 索引通常都會分解成不同部分, 分布在不同節(jié)點的部分數(shù)據(jù)就是分片。
ES 自動管理和組織分片, 并在必要的時候?qū)Ψ制瑪?shù)據(jù)進行再平衡分配, 所以用戶基本上不用擔心分片的處理細節(jié)。創(chuàng)建索引時默認的分片數(shù)為 5 個，并且一旦創(chuàng)建不能更改。
副本 (replica)
ES 默認創(chuàng)建一份副本，就是說在 5 個主分片的基礎(chǔ)上，每個主分片都相應的有一個副本分片。
額外的副本有利有弊，有副本可以有更強的故障恢復能力，但也占了相應副本倍數(shù)的磁盤空間。
那我們在創(chuàng)建索引的時候，應該創(chuàng)建多少個分片與副本數(shù)呢?對于副本數(shù)，比較好確定，可以根據(jù)我們集群節(jié)點的多少與我們的存儲空間決定。
我們的集群服務器多，并且有足夠大多存儲空間，可以多設(shè)置副本數(shù)，一般是 1-3 個副本數(shù)，如果集群服務器相對較少并且存儲空間沒有那么寬松，則可以只設(shè)定一份副本以保證容災(副本數(shù)可以動態(tài)調(diào)整)。
對于分片數(shù)，是比較難確定的，因為一個索引分片數(shù)一旦確定，就不能更改。
所以我們在創(chuàng)建索引前，要充分的考慮到，以后我們創(chuàng)建的索引所存儲的數(shù)據(jù)量，否則創(chuàng)建了不合適的分片數(shù)，會對我們的性能造成很大的影響。
對于分片數(shù)的大小，業(yè)界一致認為分片數(shù)的多少與內(nèi)存掛鉤，認為 1GB 堆內(nèi)存對應 20-25 個分片，而一個分片的大小不要超過 50G，這樣的配置有助于集群的健康。
但是我個人認為這樣的配置方法過于死板，我個人在調(diào)優(yōu) ES 集群的過程中，根據(jù)總數(shù)據(jù)量的大小，設(shè)定了相應的分片，保證每一個分片的大小沒有超過 50G(大概在 40G 左右)，但是相比之前的分片數(shù)查詢起來，效果并不明顯。
之后又嘗試了增加分片數(shù)，發(fā)現(xiàn)分片數(shù)增多之后，查詢速度有了明顯的提升，每一個分片的數(shù)據(jù)量控制在 10G 左右。
查詢大量小分片使得每個分片處理數(shù)據(jù)速度更快了，那是不是分片數(shù)越多，我們的查詢就越快，ES 性能就越好呢?
其實也不是，因為在查詢過程中，有一個分片合并的過程，如果分片數(shù)不斷的增加，合并的時間則會增加。
而且隨著更多的任務需要按順序排隊和處理，更多的小分片不一定要比查詢較小數(shù)量的更大的分片更快。如果有多個并發(fā)查詢，則有很多小碎片也會降低查詢吞吐量。
如果現(xiàn)在你的場景是分片數(shù)不合適了，但是又不知道如何調(diào)整，那么有一個好的解決方法就是按照時間創(chuàng)建索引，然后進行通配查詢。
如果每天的數(shù)據(jù)量很大，則可以按天創(chuàng)建索引，如果是一個月積累起來導致數(shù)據(jù)量很大，則可以一個月創(chuàng)建一個索引。
如果要對現(xiàn)有索引進行重新分片，則需要重建索引，我會在文章的***總結(jié)重建索引的過程。
參數(shù)調(diào)優(yōu)
下面我會介紹一些 ES 關(guān)鍵參數(shù)的調(diào)優(yōu)。有很多場景是，我們的 ES 集群占用了多大的 CPU 使用率，該如何調(diào)節(jié)呢?
CPU 使用率高，有可能是寫入導致的，也有可能是查詢導致的，那要怎么查看呢?
可以先通過 GET _nodes/{node}/hot_threads 查看線程棧，查看是哪個線程占用 CPU 高：
- 如果是 elasticsearch[{node}][search][T#10] 則是查詢導致的。
- 如果是 elasticsearch[{node}][bulk][T#1] 則是數(shù)據(jù)寫入導致的。
我在實際調(diào)優(yōu)中，CPU 使用率很高，如果不是 SSD，建議把 index.merge.scheduler.max_thread_count: 1 索引 merge ***線程數(shù)設(shè)置為 1 個，該參數(shù)可以有效調(diào)節(jié)寫入的性能。
因為在存儲介質(zhì)上并發(fā)寫，由于尋址的原因，寫入性能不會提升，只會降低。
還有幾個重要參數(shù)可以進行設(shè)置，各位同學可以視自己的集群情況與數(shù)據(jù)情況而定。
index.refresh_interval：這個參數(shù)的意思是數(shù)據(jù)寫入后幾秒可以被搜索到，默認是 1s。
每次索引的 refresh 會產(chǎn)生一個新的 lucene 段, 這會導致頻繁的合并行為，如果業(yè)務需求對實時性要求沒那么高，可以將此參數(shù)調(diào)大，實際調(diào)優(yōu)告訴我，該參數(shù)確實很給力，CPU 使用率直線下降。
indices.memory.index_buffer_size：如果我們要進行非常重的高并發(fā)寫入操作，那么***將 indices.memory.index_buffer_size 調(diào)大一些。
index buffer 的大小是所有的 shard 公用的，一般建議(看的大牛博客)，對于每個 shard 來說，最多給 512mb，因為再大性能就沒什么提升了。
ES 會將這個設(shè)置作為每個 shard 共享的 index buffer，那些特別活躍的 shard 會更多的使用這個 buffer。默認這個參數(shù)的值是 10%，也就是 jvm heap 的 10%。
translog：ES 為了保證數(shù)據(jù)不丟失，每次 index、bulk、delete、update 完成的時候，一定會觸發(fā)刷新 translog 到磁盤上。
在提高數(shù)據(jù)安全性的同時當然也降低了一點性能。如果你不在意這點可能性，還是希望性能優(yōu)先，可以設(shè)置如下參數(shù)：
- "index.translog": {
- "sync_interval": "120s", --sync間隔調(diào)高
- "durability": "async", -– 異步更新
- "flush_threshold_size":"1g" --log文件大小
- }
這樣設(shè)定的意思是開啟異步寫入磁盤，并設(shè)定寫入的時間間隔與大小，有助于寫入性能的提升。
還有一些超時參數(shù)的設(shè)置：
- discovery.zen.ping_timeout 判斷 master 選舉過程中，發(fā)現(xiàn)其他 node 存活的超時設(shè)置。
- discovery.zen.fd.ping_interval 節(jié)點被 ping 的頻率，檢測節(jié)點是否存活。
- discovery.zen.fd.ping_timeout 節(jié)點存活響應的時間，默認為 30s，如果網(wǎng)絡可能存在隱患，可以適當調(diào)大。
- discovery.zen.fd.ping_retries ping 失敗/超時多少導致節(jié)點被視為失敗，默認為 3。
其他建議
還有一些零碎的優(yōu)化建議如下：
插入索引自動生成 id：當寫入端使用特定的 id 將數(shù)據(jù)寫入 ES 時，ES 會檢查對應的索引下是否存在相同的 id。
這個操作會隨著文檔數(shù)量的增加使消耗越來越大，所以如果業(yè)務上沒有硬性需求，建議使用 ES 自動生成的 id，加快寫入速率。
避免稀疏索引：索引稀疏之后，會導致索引文件增大。ES 的 keyword，數(shù)組類型采用 doc_values 結(jié)構(gòu)。
即使字段是空值，每個文檔也會占用一定的空間，所以稀疏索引會造成磁盤增大，導致查詢和寫入效率降低。
我的調(diào)優(yōu)
下面說一說我的調(diào)優(yōu)：主要是重建索引，更改了現(xiàn)有索引的分片數(shù)量，經(jīng)過不斷的測試，找到了一個***的分片數(shù)量。
重建索引的時間是漫長的，在此期間，又對 ES 的寫入進行了相應的調(diào)優(yōu)，使 CPU 使用率降低下來。
附上我的調(diào)優(yōu)參數(shù)：
- index.merge.scheduler.max_thread_count:1 # 索引 merge ***線程數(shù)
- indices.memory.index_buffer_size:30% # 內(nèi)存
- index.translog.durability:async # 這個可以異步寫硬盤，增大寫的速度
- index.translog.sync_interval:120s #translog 間隔時間
- discovery.zen.ping_timeout:120s # 心跳超時時間
- discovery.zen.fd.ping_interval:120s # 節(jié)點檢測時間
- discovery.zen.fd.ping_timeout:120s #ping 超時時間
- discovery.zen.fd.ping_retries:6 # 心跳重試次數(shù)
- thread_pool.bulk.size:20 # 寫入線程個數(shù) 由于我們查詢線程都是在代碼里設(shè)定好的，我這里只調(diào)節(jié)了寫入的線程數(shù)
- thread_pool.bulk.queue_size:1000 # 寫入線程隊列大小
- index.refresh_interval:300s #index 刷新間隔復制代碼
關(guān)于重建索引
在重建索引之前，首先要考慮一下重建索引的必要性，因為重建索引是非常耗時的。
ES 的 reindex api 不會去嘗試設(shè)置目標索引，不會復制源索引的設(shè)置，所以我們應該在運行_reindex 操作之前設(shè)置目標索引，包括設(shè)置映射(mapping)，分片，副本等。
***步，和創(chuàng)建普通索引一樣創(chuàng)建新索引
當數(shù)據(jù)量很大的時候，需要設(shè)置刷新時間間隔，把 refresh_intervals 設(shè)置為 -1，即不刷新。
number_of_replicas 副本數(shù)設(shè)置為 0(因為副本數(shù)可以動態(tài)調(diào)整，這樣有助于提升速度)。
- {
- "settings": {
- "number_of_shards": "50",
- "number_of_replicas": "0",
- "index": {
- "refresh_interval": "-1"
- }
- }
- "mappings": {
- }
- }
第二步，調(diào)用 reindex 接口
建議加上 wait_for_completion=false 的參數(shù)條件，這樣 reindex 將直接返回 taskId。
- POST _reindex?wait_for_completion=false
- {
- "source": {
- "index": "old_index", //原有索引
- "size": 5000 //一個批次處理的數(shù)據(jù)量
- },
- "dest": {
- "index": "new_index", //目標索引
- }
- }
第三步：等待
可以通過 GET _tasks?detailed=true&actions=*reindex 來查詢重建的進度。如果要取消 task 則調(diào)用_tasks/node_id:task_id/_cancel。
第四步：刪除舊索引，釋放磁盤空間
更多細節(jié)可以查看 ES 官網(wǎng)的 reindex api。那么有的同學可能會問，如果我此刻 ES 是實時寫入的，那咋辦呀?
這個時候，我們就要重建索引的時候，在參數(shù)里加上上一次重建索引的時間戳。
直白的說就是，比如我們的數(shù)據(jù)是 100G，這時候我們重建索引了，但是這個 100G 在增加，那么我們重建索引的時候，需要記錄好重建索引的時間戳。
記錄時間戳的目的是下一次重建索引跑任務的時候不用全部重建，只需要在此時間戳之后的重建就可以，如此迭代，直到新老索引數(shù)據(jù)量基本一致，把數(shù)據(jù)流向切換到新索引的名字。
- 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" //以舊索引的數(shù)據(jù)為準
- }
- }
以上就是我在 ES 調(diào)優(yōu)上的一點總結(jié)，希望能夠幫助到對 ES 性能有困惑的同學們，謝謝大家。
