段和合並編輯

段合併的計算量龐大， 而且還要吃掉大量磁碟 I/O。合併在後臺定期操作，因為他們可能要很長時間才能完成，尤其是比較大的段。這個通常來說都沒問題，因為大規模段合併的概率是很小的。

不過有時候合併會拖累寫入速率。如果這個真的發生了，Elasticsearch 會自動限制索引請求到單個執行緒裡。這個可以防止出現 段爆炸 問題，即數以百計的段在被合併之前就生成出來。如果 Elasticsearch 發現合併拖累索引了，它會會記錄一個宣告有 now throttling indexing 的 INFO 級別資訊。

Elasticsearch 預設設定在這塊比較保守：不希望搜尋效能被後臺合併影響。不過有時候（尤其是 SSD，或者日誌場景）限流閾值太低了。

預設值是 20 MB/s，對機械磁碟應該是個不錯的設定。如果你用的是 SSD，可以考慮提高到 100–200 MB/s。測試驗證對你的系統哪個值合適：

PUT /_cluster/settings
{"persistent":{"indices.store.throttle.max_bytes_per_sec":"100mb"}}

如果你在做批量匯入，完全不在意搜尋，你可以徹底關掉合併限流。這樣讓你的索引速度跑到你磁碟允許的極限：

PUT /_cluster/settings
{"transient":{"indices.store.throttle.type":"none"}}

如果你使用的是機械磁碟而非 SSD，你需要新增下面這個配置到你的 elasticsearch.yml 裡：

index.merge.scheduler.max_thread_count: 1

機械磁碟在併發 I/O 支援方面比較差，所以我們需要降低每個索引併發訪問磁碟的執行緒數。這個設定允許 max_thread_count + 2 個執行緒同時進行磁碟操作，也就是設定為 1 允許三個執行緒。

對於 SSD，你可以忽略這個設定，預設是 Math.min(3, Runtime.getRuntime().availableProcessors() / 2)

最後，你可以增加 index.translog.flush_threshold_size 設定，從預設的 512 MB 到更大一些的值，比如 1 GB。這可以在一次清空觸發的時候在事務日誌裡積累出更大的段。而通過構建更大的段，清空的頻率變低，大段合併的頻率也變低。這一切合起來導致更少的磁碟 I/O 開銷和更好的索引速率。當然，你會需要對應量級的 heap 記憶體用以積累更大的緩衝空間，調整這個設定的時候請記住這點。