ElasticSearch優(yōu)化
一：集群節(jié)點(diǎn)規(guī)劃
elasticSearch的配置文件中有2個(gè)參數(shù)：node.master和node.data。這兩個(gè)參數(shù)搭配使用時(shí)，能夠幫助提供服務(wù)器性能。
1、數(shù)據(jù)節(jié)點(diǎn)node.master: false node.data: true
該node服務(wù)器只作為一個(gè)數(shù)據(jù)節(jié)點(diǎn)，只用于存儲索引數(shù)據(jù)。使該node服務(wù)器功能單一，只用于數(shù)據(jù)存儲和數(shù)據(jù)查詢，降低其資源消耗率。
2、master節(jié)點(diǎn)node.master:
true node.data: false
該node服務(wù)器只作為一個(gè)主節(jié)點(diǎn)，但不存儲任何索引數(shù)據(jù)。該node服務(wù)器將使用自身空閑的資源，來協(xié)調(diào)各種創(chuàng)建索引請求或者查詢請求，講這些請求合理分發(fā)到相關(guān)的node服務(wù)器上。
3、負(fù)載均衡節(jié)點(diǎn)node.master: false node.data: false
該node服務(wù)器即不會被選作主節(jié)點(diǎn)，也不會存儲任何索引數(shù)據(jù)。該服務(wù)器主要用于查詢負(fù)載均衡。在查詢的時(shí)候，通常會涉及到從多個(gè)node服務(wù)器上查詢數(shù)據(jù)，并請求分發(fā)到多個(gè)指定的node服務(wù)器，并對各個(gè)node服務(wù)器返回的結(jié)果進(jìn)行一個(gè)匯總處理，最終返回給客戶端。
一臺服務(wù)器上最好只部署一個(gè)Node
一臺物理服務(wù)器上可以啟動多個(gè)Node服務(wù)器節(jié)點(diǎn)（通過設(shè)置不同的啟動port），但一臺服務(wù)器上的CPU,內(nèi)存，硬盤等資源畢竟有限，從服務(wù)器性能考慮，不建議一臺服務(wù)器上啟動多個(gè)node節(jié)點(diǎn)。
在大規(guī)模局點(diǎn),比如100個(gè)點(diǎn)，可以專門配備3個(gè)Master，可使用3臺具有內(nèi)存的刀片即可，即參數(shù)配置為node.master:
true，node.data:
false；可以按比例配備數(shù)據(jù)匯聚節(jié)點(diǎn)，比如10個(gè)，即參數(shù)配置為node.master:
false，node.data:
false；小規(guī)模節(jié)點(diǎn)，可以不用如此設(shè)置，當(dāng)然如果依然有性能問題，也是一個(gè)優(yōu)化的措施。
關(guān)閉data節(jié)點(diǎn)服務(wù)器中的http功能：
針對ElasticSearch集群中的所有數(shù)據(jù)節(jié)點(diǎn)，不用開啟http服務(wù)。將其中的配置參數(shù)這樣設(shè)置：http.enabled:
false，同時(shí)也不要安裝head, bigdesk, marvel等監(jiān)控插件，這樣保證data節(jié)點(diǎn)服務(wù)器只需處理創(chuàng)建/更新/刪除/查詢索引數(shù)據(jù)等操作。
http功能可以在非數(shù)據(jù)節(jié)點(diǎn)服務(wù)器上開啟，上述相關(guān)的監(jiān)控插件也安裝到這些服務(wù)器上，用于監(jiān)控ElasticSearch集群狀態(tài)等數(shù)據(jù)信息。
這樣做一來出于數(shù)據(jù)安全考慮，二來出于服務(wù)性能考慮。
二：機(jī)器設(shè)置（內(nèi)存）
1、預(yù)留一半內(nèi)存給Lucene使用
一個(gè)常見的問題是配置堆太大。你有一個(gè)64 GB的機(jī)器，覺得JVM內(nèi)存越大越好，想給Elasticsearch所有64 GB的內(nèi)存。
當(dāng)然，內(nèi)存對于Elasticsearch來說絕對是重要的，用于更多的內(nèi)存數(shù)據(jù)提供更快的操作。而且還有一個(gè)內(nèi)存消耗大戶-Lucene
Lucene的設(shè)計(jì)目的是把底層OS里的數(shù)據(jù)緩存到內(nèi)存中。Lucene的段是分別存儲到單個(gè)文件中的，這些文件都是不會變化的，所以很利于緩存，同時(shí)操作系統(tǒng)也會把這些段文件緩存起來，以便更快的訪問。
Lucene的性能取決于和OS的交互，如果你把所有的內(nèi)存都分配給Elasticsearch，不留一點(diǎn)給Lucene，那你的全文檢索性能會很差的。
最后標(biāo)準(zhǔn)的建議是把50%的內(nèi)存給elasticsearch，剩下的50%也不會沒有用處的，Lucene會很快吞噬剩下的這部分內(nèi)存。
2、32GB限制
給ES的內(nèi)存配置不是越大越好，建議不能超過32GB，不同jdk版本最大邊界值是不同的，對于32位小于32G JVM才采用內(nèi)存對象指針壓縮技術(shù)，不然對象指針需要占用很大的內(nèi)存
使用如下命令測試最大邊界值：
java-Xmx32767m -XX:+PrintFlagsFinal2>/dev/null |grep UseCompressedOops
boolUseCompressedOops= false{lp64_product}
java -Xmx32766m -XX:+PrintFlagsFinal2>/dev/null |grep UseCompressedOops
bool UseCompressedOops= true{lp64_product}
$ JAVA_HOME=`/usr/libexec/java_home
-v 1.8` java -Xmx32766m -XX:+PrintFlagsFinal 2> /dev/null | grepUseCompressedOops
boolUseCompressedOops:= true
$ JAVA_HOME=`/usr/libexec/java_home
-v 1.8` java -Xmx32767m -XX:+PrintFlagsFinal 2> /dev/null | grepUseCompressedOops
bool UseCompressedOops= false
在ES啟動日志中最好能夠看到壓縮對象指針為真。
heap size [15.8gb], compressed ordinary object pointers [true]
在java中，所有的對象都分配在堆上，然后有一個(gè)指針引用它。指向這些對象的指針大小通常是CPU的字長的大小，不是32bit就是64bit，這取決于你的處理器，指針指向了你的值的精確位置。
對于32位系統(tǒng)，你的內(nèi)存最大可使用4G。對于64系統(tǒng)可以使用更大的內(nèi)存。但是64位的指針意味著更大的浪費(fèi)，因?yàn)槟愕闹羔槺旧泶罅?。浪費(fèi)內(nèi)存不算，更糟糕的是，更大的指針在主內(nèi)存和緩存器（例如LLC, L1等）之間移動數(shù)據(jù)的時(shí)候，會占用更多的帶寬。
java使用一個(gè)叫內(nèi)存指針壓縮的技術(shù)來解決這個(gè)問題。它的指針不再表示對象在內(nèi)存中的精確位置，而是表示偏移量。這意味著32位的指針可以引用40億個(gè)對象，而不是40億個(gè)字節(jié)。最終，也就是說堆內(nèi)存長到32G的物理內(nèi)存，也可以用32bit的指針表示。
一旦你越過那個(gè)神奇的30-32G的邊界，指針就會切回普通對象的指針，每個(gè)對象的指針都變長了，就會使用更多的CPU內(nèi)存帶寬，也就是說你實(shí)際上失去了更多的內(nèi)存。事實(shí)上當(dāng)內(nèi)存到達(dá)40-50GB的時(shí)候，有效內(nèi)存才相當(dāng)于使用內(nèi)存對象指針壓縮技術(shù)時(shí)候的32G內(nèi)存。
這段描述的意思就是說：即便你有足夠的內(nèi)存，也盡量不要超過32G，因?yàn)樗速M(fèi)了內(nèi)存，降低了CPU的性能，還要讓GC應(yīng)對大內(nèi)存。
3、機(jī)器內(nèi)存大于64GB
你可以考慮一臺機(jī)器上創(chuàng)建兩個(gè)或者更多ES節(jié)點(diǎn)，而不要部署一個(gè)使用32+GB內(nèi)存的節(jié)點(diǎn)。仍然要堅(jiān)持50%原則，假設(shè)你有個(gè)機(jī)器有128G內(nèi)存，你可以創(chuàng)建兩個(gè)node，使用32G內(nèi)存。也就是說64G內(nèi)存給ES的堆內(nèi)存，剩下的64G給Lucene。
如果你選擇第二種，你需要配置cluster.routing.allocation.same_shard.host:true。這會防止同一個(gè)shard的主副本存在同一個(gè)物理機(jī)上（因?yàn)槿绻嬖谝粋€(gè)機(jī)器上，副本的高可用性就沒有了）
4、swapping是性能的墳?zāi)?/p>
這是顯而易見的，但是還是有必要說的更清楚一點(diǎn)，內(nèi)存交換到磁盤對服務(wù)器性能來說是致命的。想想看一個(gè)內(nèi)存的操作必須是快速的。
如果內(nèi)存交換到磁盤上，一個(gè)100微秒的操作可能變成10毫秒，再想想那么多10微秒的操作時(shí)延累加起來。不難看出swapping對于性能是多么可怕。
最好的辦法就是在你的操作系統(tǒng)中完全禁用swapping。這樣可以暫時(shí)禁用：
sudo swapoff -a
為了永久禁用它，你可能需要修改/etc/fstab文件，這要參考你的操作系統(tǒng)相關(guān)文檔。
如果完全禁用swap，對你來說是不可行的。你可以降低swappiness的值，這個(gè)值決定操作系統(tǒng)交換內(nèi)存的頻率。這可以預(yù)防正常情況下發(fā)生交換。但仍允許os在緊急情況下發(fā)生交換。對于大部分Linux操作系統(tǒng)，可以在sysctl中這樣配置：
vm.swappiness = 1
備注：swappiness設(shè)置為1比設(shè)置為0要好，因?yàn)樵谝恍﹥?nèi)核版本，swappness=0會引發(fā)OOM（內(nèi)存溢出）
最后，如果上面的方法都不能做到，你需要打開配置文件中的mlockall開關(guān)，它的作用就是運(yùn)行JVM鎖住內(nèi)存，禁止OS交換出去。在elasticsearch.yml配置如下：bootstrap.mlockall: true
5、heap參數(shù)設(shè)置優(yōu)化
命令行修改
./bin/elasticsearch-Xmx10g -Xms10g
xmx-JVM最大允許分配的堆內(nèi)存，按需分配
xms-JVM初始分配的堆內(nèi)存
此值設(shè)置與-Xmx相同，以避免每次垃圾回收完成后JVM重新分配內(nèi)存。
對Unix系統(tǒng)，可修改./bin/elasticsearch.in.sh文件：
一般分配主機(jī)1/4-1/2的內(nèi)存
if["x$ES_MIN_MEM"=
"x"];then
ES_MIN_MEM=12g
fi
if["x$ES_MAX_MEM"=
"x"];then
ES_MAX_MEM=12g
fi
JAVA_OPTS="$JAVA_OPTS
-Xms${ES_MIN_MEM}"
JAVA_OPTS="$JAVA_OPTS-Xmx${ES_MAX_MEM}"
線程大小, ES單線程承載的數(shù)據(jù)量比較大
JAVA_OPTS="$JAVA_OPTS
-Xss128m"
三：機(jī)器設(shè)置（硬盤、CPU）
硬盤對集群非常重要，特別是建索引多的情況。磁盤是一個(gè)服務(wù)器最慢的系統(tǒng)，對于寫比較重的集群，磁盤很容易成為集群的瓶頸。
如果可以承擔(dān)的器SSD盤，最好使用SSD盤。如果使用SSD，最好調(diào)整I/O調(diào)度算法。RAID0是加快速度的不錯(cuò)方法。
ES建議機(jī)器配置：64G內(nèi)存SSD硬盤RAID0，不要使用NAS。
1、自動調(diào)整存儲帶寬
在2.0.0之前，elasticsearch會限制合并速度（merges），默認(rèn)為20MB/sec。但是這個(gè)速率經(jīng)常是顯得太小，導(dǎo)致合并速度落后于索引速度，進(jìn)而限制了索引速度。
現(xiàn)在Elasticsearch2.0.0，使用了自動調(diào)整合并IO速度方式：如果合并落于索引速度，合并IO速度會逐漸增大，并且隨著合并的持續(xù)進(jìn)行會減小。在索引吞吐量小的時(shí)候，即使突然來了一個(gè)大的合并任務(wù)，這種情況也不會吞噬整個(gè)節(jié)點(diǎn)可用的IO，極小化的降低對正在進(jìn)行的查詢和索引的影響。
但是對索引請求大的情況下，允許的合并速度會自動調(diào)整到跟上索引的速度。
有了2.0.0這個(gè)特性，意味著我們不需要管任何的限制值了，只要用默認(rèn)的就好了。
2.0.0之前store throttle設(shè)置值有如下幾個(gè)，在2.0.0版本已經(jīng)刪除了。
indices.store.throttle.type,
indices.store.throttle.max_bytes_per_sec,
index.store.throttle.type,
index.store.throttle.max_bytes_per_sec
另外，Recovery/snapshot/restore仍然是有速度限制的，默認(rèn)都是20MB/sec。
2、多個(gè)path.data路徑
如果磁盤空間和IO性能是Elasticsearch的瓶頸的話，使用多個(gè)IO設(shè)備（通過設(shè)置多個(gè)path.data路徑）存儲shards，能夠增加總的存儲空間和提升IO性能。
在Elasticsearch2.0之前的版本，也是配置多個(gè)path.data路徑，但是其相當(dāng)于RAID
0，每個(gè)shards的數(shù)據(jù)會分布在所有的磁盤上。當(dāng)一個(gè)節(jié)點(diǎn)上有一塊盤壞了的情況下，該節(jié)點(diǎn)上所有的shards都會損壞了。需要恢復(fù)該節(jié)點(diǎn)上的所有shards。
在2.0.0版本，把這個(gè)實(shí)現(xiàn)改成了：每個(gè)shards所有的數(shù)據(jù)只會在一塊磁盤上面。這樣即使一個(gè)節(jié)點(diǎn)的一塊磁盤損壞了，也只是損失了該磁盤上的shards，其它磁盤上的shards安然無事。只需要恢復(fù)該塊盤上的shards即可。
升級到2.0.0版本時(shí)，舊版本一個(gè)shard分布到所有磁盤上的數(shù)據(jù)，會拷貝到一塊盤上。
對應(yīng)這個(gè)改變，在設(shè)計(jì)shards時(shí)，如果一個(gè)節(jié)點(diǎn)有10塊磁盤，共3個(gè)節(jié)點(diǎn)，則shards至少30個(gè)，才能分布在30塊盤上（即最大限度使用磁盤空間）。
參考
https://www.elastic.co/blog/performance-indexing-2.0
https://www.elastic.co/guide/en/elasticsearch/guide/current/hardware.html
3、CPU（threadpool）
線程不是越大越好，一般設(shè)置threadpool數(shù)為CPU cores的個(gè)數(shù)
搜索：int((# of cores * 3) / 2) + 1
ElasticSearch服務(wù)器有多個(gè)線程池大小配置。主要有：index，search，suggest，get，bulk，percolate，snapshot，snapshot_data，warmer，refresh。
在此主要針對index和search進(jìn)行一個(gè)配置調(diào)整。index操作包含：創(chuàng)建/更新/刪除索引數(shù)據(jù)。search操作主要針對用戶的各種搜索操作。
具體配置如下：
threadpool:
index:
type:fixed
size:100
search:
type:fixed
size:1000
參考文檔
https://www.elastic.co/guide/en/elasticsearch/guide/current/heap-sizing.html
四：索引過程
大家可能會遇到索引數(shù)據(jù)比較慢的過程。其實(shí)明白索引的原理就可以有針對性的進(jìn)行優(yōu)化。ES索引的過程到相對Lucene的索引過程多了分布式數(shù)據(jù)的擴(kuò)展，而這ES主要是用tranlog進(jìn)行各節(jié)點(diǎn)之間的數(shù)據(jù)平衡。所以從上我可以通過索引的settings進(jìn)行第一優(yōu)化：
"index.translog.flush_threshold_ops":"10000"
"refresh_interval"
: "1s"
這兩個(gè)參數(shù)第一是到translog數(shù)據(jù)達(dá)到多少條進(jìn)行平衡，默認(rèn)為5000，而這個(gè)過程相對而言是比較浪費(fèi)時(shí)間和資源的。所以我們可以將這個(gè)值調(diào)大一些還是設(shè)為-1關(guān)閉，進(jìn)而手動進(jìn)行translog平衡。第二參數(shù)是刷新頻率，默認(rèn)為1s是指索引在生命周期內(nèi)定時(shí)刷新，一但有數(shù)據(jù)進(jìn)來能refresh像lucene里面commit,我們知道當(dāng)數(shù)據(jù)addDoucment后，還不能檢索到要commit之后才能行數(shù)據(jù)的檢索，所以可以將其關(guān)閉，在最初索引完后手動refresh之，然后將索引setting里面的index.refresh_interval參數(shù)按需求進(jìn)行修改，從而可以提高索引過程效率。
另外的知道ES索引過程中如果有副本存在，數(shù)據(jù)也會馬上同步到副本中去。我個(gè)人建議在索引過程中將副本數(shù)設(shè)為0，待索引完成后將副本數(shù)按需量改回來，這樣也可以提高索引效率。
“number_of_replicas”:
0
其實(shí)檢索速度快度與索引質(zhì)量有很大的關(guān)系。而索引質(zhì)量的好壞主要與以下幾方面有關(guān)：
1、分片數(shù)
分片數(shù)是與檢索速度非常相關(guān)的的指標(biāo)，如果分片數(shù)過少或過多都會導(dǎo)致檢索比較慢。分片數(shù)過多會導(dǎo)致檢索時(shí)打開比較多的文件別外也會導(dǎo)致多臺服務(wù)器之間通訊。而分片數(shù)過少會導(dǎo)致單個(gè)分片索引過大，所以檢索速度慢?；谒饕制瑪?shù)=數(shù)據(jù)總量/單分片數(shù)的計(jì)算公式，在確定分片數(shù)之前需要進(jìn)行單服務(wù)單索引單分片的測試，目前我們測試的結(jié)果單個(gè)分片的內(nèi)容為10G。
分片（Shard）：一個(gè)索引會分成多個(gè)分片存儲，分片數(shù)量在索引建立后不可更改，推薦【分片數(shù)*副本數(shù)=集群數(shù)量】
2、確定分片(shard)的數(shù)量和副本(replica)的數(shù)量
ElasticSearch在創(chuàng)建索引數(shù)據(jù)時(shí)，最好指定相關(guān)的shards數(shù)量和replicas，否則會使用服務(wù)器中的默認(rèn)配置參數(shù)shards=5，replicas=1。
因?yàn)檫@兩個(gè)屬性的設(shè)置直接影響集群中索引和搜索操作的執(zhí)行。假設(shè)你有足夠的機(jī)器來持有碎片和副本，那么可以按如下規(guī)則設(shè)置這兩個(gè)值：
1)擁有更多的碎片可以提升索引執(zhí)行能力，并允許通過機(jī)器分發(fā)一個(gè)大型的索引；
2)擁有更多的副本能夠提升搜索執(zhí)行能力以及集群能力。
對于一個(gè)索引來說，number_of_shards只能設(shè)置一次，而number_of_replicas可以使用索引更新設(shè)置API在任何時(shí)候被增加或者減少。
這兩個(gè)配置參數(shù)在配置文件的配置如下：
index.number_of_shards: 5
number_of_replicas:1
Elastic官方文檔建議：一個(gè)Node中一個(gè)索引最好不要多于三個(gè)shards.配置total_shards_per_node參數(shù)，限制每個(gè)index每個(gè)節(jié)點(diǎn)最多分配多少個(gè)發(fā)片.
http://www.open-open.com/doc/view/f240d61f8f7745098b4459c2483feb40
3、副本數(shù)
副本數(shù)與索引的穩(wěn)定性有比較大的關(guān)系，如果Node在非正常掛了，經(jīng)常會導(dǎo)致分片丟失，為了保證這些數(shù)據(jù)的完整性，可以通過副本來解決這個(gè)問題。建議在建完索引后在執(zhí)行Optimize后，馬上將副本數(shù)調(diào)整過來。
4、分詞
分詞對于索引的影響可大可小，看自己把握。大家或許認(rèn)為詞庫越多，分詞效果越好，索引質(zhì)量越好，其實(shí)不然。分詞有很多算法，大部分基于詞表進(jìn)行分詞。也就是說詞表的大小決定索引大小。所以分詞與索引膨漲率有直接關(guān)系。詞表不應(yīng)很多，而對文檔相關(guān)特征性較強(qiáng)的即可。比如論文的數(shù)據(jù)進(jìn)行建索引，分詞的詞表與論文的特征越相似，詞表數(shù)量越小，在保證查全查準(zhǔn)的情況下，索引的大小可以減少很多。索引大小減少了，那么檢索速度也就提高了。
5、索引段
索引段即lucene中的segments概念，我們知道ES索引過程中會refresh和tranlog也就是說我們在索引過程中segments number不只一個(gè)。而segments number與檢索是有直接聯(lián)系的，segments number越多檢索越慢，而將segments numbers有可能的情況下保證為1，這將可以提高將近一半的檢索速度。
https://www.elastic.co/guide/en/elasticsearch/guide/current/hardware.html
優(yōu)化建議
1.目前Elasticsearch5.x運(yùn)行在Oracle JDK1.8以上環(huán)境中，ES性能體現(xiàn)在在分布式計(jì)算中，一個(gè)節(jié)點(diǎn)是不足以測試出其性能，一個(gè)生產(chǎn)系統(tǒng)至少在三個(gè)節(jié)點(diǎn)以上。
2.ES集群節(jié)點(diǎn)規(guī)劃良好，master、node、client分離開來，data節(jié)點(diǎn)關(guān)閉http功能。
3.合理利用內(nèi)存。
a) JVM內(nèi)存設(shè)置不要超過機(jī)器的一半內(nèi)存，并且不超過32G。（./bin/elasticsearch -Xmx10g -Xms10g或者修改./bin/elasticsearch.in.sh文件：
一般分配主機(jī)1/4-1/2的內(nèi)存
if["x$ES_MIN_MEM"=
"x"];then
ES_MIN_MEM=12g
fi
if["x$ES_MAX_MEM"=
"x"];then
ES_MAX_MEM=12g
fi
JAVA_OPTS="$JAVA_OPTS
-Xms${ES_MIN_MEM}"
JAVA_OPTS="$JAVA_OPTS
-Xmx${ES_MAX_MEM}"
設(shè)置每個(gè)線程的堆棧大小, ES單線程承載的數(shù)據(jù)量比較大
JAVA_OPTS="$JAVA_OPTS -Xss128m"
b)修改swapping參數(shù)，內(nèi)存不夠用時(shí)才進(jìn)行swapping（vm.swappiness=
1）
c)暫時(shí)不要修改GC方法
d）鎖定內(nèi)存，不讓JVM寫入swapping，避免降低ES的性能
bootstrap.mlockall: true
e）緩存類型設(shè)置為Soft Reference，只有當(dāng)內(nèi)存不夠時(shí)才會進(jìn)行回收
index.cache.field.max_size:50000
index.cache.field.expire: 10m
index.cache.field.type: soft
4.權(quán)衡建索引的性能和檢索的時(shí)效性，修改以下參數(shù)。
“index.translog.flush_threshold_ops”:”10000”
“index.refresh_interval”:1
“number_of_replicas”: 0
5.倒排詞典的索引需要常駐內(nèi)存，無法GC，需要監(jiān)控data node上segment
memory增長趨勢。
定期對不再更新的索引做optimize (ES2.0以后更改為force merge api)。這Optimze的實(shí)質(zhì)是對segment file強(qiáng)制做合并，可以節(jié)省大量的segment memory
6.根據(jù)機(jī)器數(shù)，磁盤數(shù)，索引大小等硬件環(huán)境，根據(jù)測試結(jié)果，設(shè)置最優(yōu)的分片數(shù)和備份數(shù)，單個(gè)分片最好不超過10GB，定期刪除不用的索引，做好冷數(shù)據(jù)的遷移。
7.保守配置內(nèi)存限制參數(shù)，盡量使用doc value存儲以減少內(nèi)存消耗，查詢時(shí)限制size、from參數(shù)。
8.如果不使用_all字段最好關(guān)閉這個(gè)屬性，否則在創(chuàng)建索引和增大索引大小的時(shí)候會使用額外更多的CPU，如果你不受限CPU計(jì)算能力可以選擇壓縮文檔的_source。這實(shí)際上就是整行日志，所以開啟壓縮可以減小索引大小。
9.避免返回大量結(jié)果集的搜索與聚合。缺失需要大量拉取數(shù)據(jù)可以采用scan &
scroll api來實(shí)現(xiàn)。
10.熟悉各類緩存作用，如field cache, filter cache, indexing cache, bulk queue等等，要設(shè)置合理的大小，并且要應(yīng)該根據(jù)最壞的情況來看heap是否夠用。
11.必須結(jié)合實(shí)際應(yīng)用場景，并對集群使用情況做持續(xù)的監(jiān)控。
