1. 64 GB 內存的機器是非常理想的，但是 32 GB 和 16 GB 機器也是很常見的。少于 8 GB 會適得其反。 2. 如果你要在更快的 CPUs 和更多的核心之間選擇，選擇更多的核心更好。多個內核提供的額外并發遠勝過稍微快一點點的時鐘頻率。 3. 如果你負擔得起 SSD磁盤，它將遠遠超出任何旋轉介質。 基于 SSD 的節點，查詢和索引性能都有提升。 4. 即使數據中心們近在咫尺，也要避免集群跨越多個數據中心。絕對要避免集群跨越大的地理距離。 5. 請確保運行你應用程序的 JVM 和服務器的 JVM 是完全一樣的。 在 Elasticsearch 的幾個地方，使用 Java 的本地序列化。 6. 通過設置 `gateway.recover_after_nodes`、`gateway.expected_nodes`、`gateway.recover_after_time` 可以在集群重啟的時候避免過多的分片交換，這可能會讓數據恢復從數個小時縮短為幾秒鐘。 7. Elasticsearch 默認被配置為使用單播發現，以防止節點無意中加入集群。只有在同一臺機器上運行的節點才會自動組成集群。最好使用單播代替組播。 8. 不要隨意修改垃圾回收器（CMS）和各個線程池的大小。 9. 把你的內存的（少于）一半給 Lucene（但不要超過 32 GB！），通過 ES_HEAP_SIZE 環境變量設置。 10. 內存交換到磁盤對服務器性能來說是致命的。如果內存交換到磁盤上，一個 100 微秒的操作可能變成 10 毫秒。 再想想那么多 10 微秒的操作時延累加起來。 不難看出 swapping 對于性能是多么可怕。 11. Lucene 使用了大量的文件。同時，Elasticsearch 在節點和 HTTP 客戶端之間進行通信也使用了大量的套接字。 所有這一切都需要足夠的文件描述符。你應該增加你的文件描述符，設置一個很大的值，如 64,000。 索引階段性能提升方法： 1. 使用批量請求并調整其大小：每次批量數據 5–15 MB 大是個不錯的起始點。 2. 存儲：使用 SSD。 3. 段與合并：Elasticsearch 默認值是 20 MB/s，對機械磁盤應該是個不錯的設置。如果你用的是 SSD，可以考慮提高到 100–200 MB/s。如果你在做批量導入，完全不在意搜索，你可以徹底關掉合并限流。另外還可以增加 `index.translog.flush_threshold_size: 512MB` 設置，從默認的 512 MB 到更大一些的值，比如 1 GB，這可以在一次清空觸發的時候在事務日志里積累出更大的段。 4. 如果你的搜索結果不需要近實時的準確度，考慮把每個索引的 `index.refresh_interval: 1s` 改到 30s，延長刷新周期，減少IO次數。 5. 如果你在做大批量導入，考慮通過設置 `index.number_of_replicas: 0` 關閉副本。