之前公司專案中有使用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'

執行原理

熱點執行緒檢測執行流程如下：

1. elasticsearch選取所有執行的執行緒，收集執行緒花費CPU的各種資訊。
2. 等待interval引數指定的時間後，再次收集步驟1中同樣的資訊。
3. 對執行緒基於其消耗的時間進行排序，取前N（引數threads決定）執行緒分析
4. 每隔幾毫秒，對3中選擇的執行緒獲取一些堆疊的快照，（數量由snapshots引數決定）
5. 組合堆疊資訊，返回響應

返回的響應包括：執行緒所屬節點、消耗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技術棧的文章。