Elasticsearch效能優化建議
之前公司專案中有使用Elasticsearch儲存日誌,當時使用的功能簡單,並沒有深入瞭解Elasticsearch,但是對於該支援文字搜尋的儲存架構還是很感興趣,最近因為想在一個新專案中採用ELK(Elasticsearch+Logstash+Kibana)技術棧來儲存系統日誌,學習有關Elasticsearch的書籍(深入理解Elasticsearch,第二版),現在就書本的第八章——提高效能,總結一些有關使用Elasticsearch的Tips,該書採用的elasticsearch為1.4.X版本。
熱點執行緒檢測
熱點執行緒API能向你提供系統變慢變卡頓的必需資訊,它給出了什麼可能是熱點的資訊,並使你可以看到系統的哪部分需要更深入的分析,例如查詢的執行或者Lucene段的合併。熱點執行緒API返回從CPU的角度來看,elasticsearch哪部分的程式碼可能是熱點的資訊,或者由於某些原因elasticsearch卡在了哪裡。
使用方法
通過使用如下的命令你可以檢視所有節點或者某些、某個節點的情況。
/_nodes/hot_threads
/_nodes/{node or nodes}/hot_threads
例如為了檢視所有節點上的熱點執行緒,你可以執行如下的命令:curl 'localhost:9200/_nodes/hot_threads'
此API支援的引數包括
- threads 需要分析的執行緒數,預設3
- interval 前後兩次檢查的時間間隔
- type 需要檢查的執行緒狀態的型別,預設是CPU,可以是阻塞、等待等執行緒狀態
- snapshots 需要生產堆疊跟蹤快照的數量
例如,想要以1s為週期檢視所有節點上處於等待狀態的熱點執行緒,可以執行命令:curl 'localhost:9200/_nodes/hot_threads?type=wait&interval=1s'
執行原理
熱點執行緒檢測執行流程如下:
- elasticsearch選取所有執行的執行緒,收集執行緒花費CPU的各種資訊。
- 等待interval引數指定的時間後,再次收集步驟1中同樣的資訊。
- 對執行緒基於其消耗的時間進行排序,取前N(引數threads決定)執行緒分析
- 每隔幾毫秒,對3中選擇的執行緒獲取一些堆疊的快照,(數量由snapshots引數決定)
- 組合堆疊資訊,返回響應
返回的響應包括:執行緒所屬節點、消耗CPU時間的百分比、使用CPU的方式、執行緒名,最後跟著一個堆疊跟蹤資訊,通過以上資訊可以定位節點的效能問題。
高負載場景的分類
高負載場景可以分為三種情況:
- 專注於高索引負載
- 專注於高查詢負載
- 高查詢索引負載並行
後面按照三個場景進行說明
查詢、索引負載均衡場景
因為是查詢、索引負載均衡的場景,所以一下建議不只是與索引效能、查詢效能有關,而是與它們都有關。
正確的儲存
選擇正確的儲存實現,在執行1.3版本以後時尤其重要。
- 如果使用64位系統,考慮使用 mmapfs(記憶體對映)
- 基於UNIX系統考慮選擇 Niofs
- windows系統應該選擇 simplefs
- 非持久化的儲存考慮 記憶體儲存
elasticsearch 1.3版本以後,預設使用的儲存型別是一個 混合 的儲存型別default,使用記憶體對映檔案讀取term字典,doc values,其他檔案採用nio儲存。
索引重新整理頻率
索引重新整理的頻率是指文件需要多長時間才能出現在搜尋結果中。規則非常簡單:重新整理頻率越短,查詢越慢,且索引文件的吞吐量越低。預設的重新整理頻率是1s,這意味著索引查詢器每1s都會重新開啟一次。如果可以接受一個較慢的重新整理頻率,可以設定成5s、10s、30s等。
執行緒池調優
但你看到節點正在填充佇列並且仍然有計算能力剩餘,且這些計算能力可以被指定用於處理等待處理操作。執行緒池調優包括執行緒數以及等待佇列長度兩個方面。
調整合並過程
Lucene段合併取決與你追加多少資料、多久追加一次等因素,對於Lucene分段和合並,需要記住:有多個段的索引執行查詢比只有少量段的索引上執行慢。效能測試顯示多個段上執行查詢比只有一個段的索引要慢大約10%-15%。
- 如果你希望查詢快,就需要更少的段
段合併限流,預設情況下elasticsearch會限制合併的速度在20MB/s,elasticsearch需要限流來避免合併過程中過多的影響搜尋。如果使用的是SSD硬碟,那麼預設20MB/s是不適合的,通過一下引數設定:
- indices.store.throttle.max_bytes_per_sec設定端合併限流
高查詢頻率場景
快取設定
第一個有助於查詢效能的快取是 過濾器快取 ,可以使用下面的屬性,來控制給定節點上能夠被過濾器快取使用的全部記憶體數量,預設是10%。indices.cache.filter.size
第二個快取是 分片查詢快取 ,她的目的是快取聚合、提示詞結果、命中數等,當你的查詢使用了聚合、提示詞等,最好啟用這個快取。該快取的大小可以使用如下引數設定:indices.cache.query.size
查詢的思考
- 總是考慮到優化查詢結構、過濾器使用等
- 過濾器不影響文件的打分,在計算得分時不被考慮進去
使用路由
如果資料可以使用路由,你應該考慮使用它,可以避免在請求特定資料查詢時查詢所有的分片。
控制size和shard_size
在處理聚合查詢時,合理的設定size、shard_size,size定義了聚合結果返回多少組資料,聚合只會返回前size個結果給客戶端;size、shard_size具有相同的意思,只是shard_size其作用是在分片的層次上。
高索引吞吐場景
批量索引
合理的使用批量索引可以顯著提高索引的速度,但不要向elasticsearch傳送過多的超出其能力的批量索引請求。
doc value 與索引速度的權衡
doc value可以幫助具有 排序、聚合、分組 的操作,但是記錄doc value需要在索引時做一些額外的操作,這樣會 降低索引速度 和 索引吞吐量 ,所以需要結合具體應用場景,權衡 doc value與索引速度。
控制文件的欄位
儘量的保持你儲存的欄位儘可能的少,你在打多少情況下需要儲存的欄位是_source,在一些場景下需要判斷是否需要儲存 _all、_source 等欄位。
在禁用_all欄位時,設定一個新的預設搜尋欄位是一個很好的實踐,使用如下命令設定:index.query.default_field:set_your_name
調整事務日誌
elasticsearch使用事務日誌來獲取最新的更新,確保資料的持久化以及優化Lucene索引的寫入,預設的事務日誌最多保留5000個操作,或者最多佔用200MB的空間。兩者的引數設定如下:
index.translog.flush_threshold_ops
index.translog.flush_threshold_size
如果需要獲取更大的索引吞吐量,願意付出資料在更長的時間內不能被搜尋到,可以調高以上兩個預設值。並且在故障發生時,擁有大量事務日誌的節點需要更長時間去恢復。
最後
以上是有關elasticsearch使用中的小Tips,後期有時間會繼續寫一些有關elk技術棧的文章。