1. 儘量執行在Sun/Oracle JDK1.7以上環境中，低版本的jdk容易出現莫名的bug，ES效能體現在在分散式計算中，一個節點是不足以測試出其效能，一個生產系統至少在三個節點以上。
   

2. ES叢集節點規劃良好，master、node、client分離開來，data節點關閉http功能。
   

3. 合理利用記憶體。
   

a) JVM記憶體設定不要超過機器的一半記憶體，並且不超過32G。（./bin/elasticsearch -Xmx10g -Xms10g或者修改./bin/elasticsearch.in.sh檔案：

** 一般分配主機1/4-1/2的記憶體**

if [ "x$ES_MIN_MEM" = "x" ]; then
ES_MIN_MEM=1024m
fi
if [ "x$ES_MAX_MEM" = "x" ]; then
ES_MAX_MEM=1024m
fi


ES_JAVA_OPTS="$ES_JAVA_OPTS -Xms${ES_MIN_MEM}"


ES_JAVA_OPTS="$ES_JAVA_OPTS -Xmx${ES_MAX_MEM}"
 

設定每個執行緒的堆疊大小, ES單執行緒承載的資料量比較大

ES_JAVA_OPTS="$ES_JAVA_OPTS -Xss3m"

b) 修改swapping引數，記憶體不夠用時才進行swapping（vm.swappiness= 1）
c) 暫時不要修改GC方法
d）鎖定記憶體，不讓JVM寫入swapping，避免降低ES的效能
bootstrap.mlockall: true
e）快取型別設定為Soft Reference，只有當記憶體不夠時才會進行回收
index.cache.field.max_size: 50000 index.cache.field.expire: 10m index.cache.field.type: soft

4.權衡建索引的效能和檢索的時效性，修改以下引數。

“index.translog.flush_threshold_ops”:”10000”
“index.refresh_interval”:1
“number_of_replicas”: 0

5.倒排詞典的索引需要常駐記憶體，無法GC，需要監控data node上segment
memory增長趨勢。

定期對不再更新的索引做optimize (ES2.0以後更改為force merge api)。這Optimze的實質是對segment file強制做合併，可以節省大量的segment memory

6.根據機器數，磁碟數，索引大小等硬體環境，根據測試結果，設定最優的分片數和備份數，單個分片最好不超過10GB，定期刪除不用的索引，做好冷資料的遷移。

7.保守配置記憶體限制引數，儘量使用doc value儲存以減少記憶體消耗，查詢時限制size、from引數。

8.如果不使用_all欄位最好關閉這個屬性，否則在建立索引和增大索引大小的時候會使用額外更多的CPU，如果你不受限CPU計算能力可以選擇壓縮文件的_source。這實際上就是整行日誌，所以開啟壓縮可以減小索引大小。

9.避免返回大量結果集的搜尋與聚合。缺失需要大量拉取資料可以採用scan & scroll api來實現。

10.熟悉各類快取作用，如field cache, filter cache, indexing cache, bulk queue等等，要設定合理的大小，並且要應該根據最壞的情況來看heap是否夠用。

11.必須結合實際應用場景，並對叢集使用情況做持續的監控。