ElasticSearch優(yōu)化系列一：集群節(jié)點規(guī)劃 - 簡書
http://www.itdecent.cn/p/4c57a246164c
節(jié)點職責單一，各司其職
elasticSearch的配置文件中有2個參數(shù)：node.master和node.data。這兩個參 數(shù)搭配使用時，能夠幫助提供服務器性能。
數(shù)據(jù)節(jié)點node.master: false node.data: true
該node服務器只作為一個數(shù)據(jù)節(jié)點，只用于存儲索引數(shù)據(jù)。使該node服務器功能 單一，只用于數(shù)據(jù)存儲和數(shù)據(jù)查詢，降低其資源消耗率。
master節(jié)點node.master: true node.data: false
該node服務器只作為一個主節(jié)點，但不存儲任何索引數(shù)據(jù)。該node服務器將使用 自身空閑的資源，來協(xié)調各種創(chuàng)建索引請求或者查詢請求，講這些請求合理分發(fā)到相關 的node服務器上。
負載均衡節(jié)點 node.master: false node.data: false
該node服務器即不會被選作主節(jié)點，也不會存儲任何索引數(shù)據(jù)。該服務器主要用 于查詢負載均衡。在查詢的時候，通常會涉及到從多個node服務器上查詢數(shù)據(jù)，并請 求分發(fā)到多個指定的node服務器，并對各個node服務器返回的結果進行一個匯總處理， 最終返回給客戶端。
關閉data節(jié)點服務器中的http功能
針對ElasticSearch集群中的所有數(shù)據(jù)節(jié)點，不用開啟http服務。將其中的配置 參數(shù)這樣設置：http.enabled: false，同時也不要安裝head, bigdesk, marvel等監(jiān)控 插件，這樣保證data節(jié)點服務器只需處理創(chuàng)建/更新/刪除/查詢索引數(shù)據(jù)等操作。http功能可以在非數(shù)據(jù)節(jié)點服務器上開啟，上述相關的監(jiān)控插件也安裝到這些服 務器上，用于監(jiān)控ElasticSearch集群狀態(tài)等數(shù)據(jù)信息。這樣做一來出于數(shù)據(jù)安全考慮，二來出于服務性能考慮。
一臺服務器上最好只部署一個Node
一臺物理服務器上可以啟動多個Node服務器節(jié)點（通過設置不同的啟動port），但一臺服務器上的CPU,內存，硬盤等資源畢竟有限，從服務器性能考慮，不建議一臺服務器上啟動多個node節(jié)點。
在大規(guī)模局點,比如100個點，可以專門配備3個Master，可使用3臺具有內存的刀片即可，即參數(shù)配置為node.master: true，node.data: false；可以按比例配備數(shù)據(jù)匯聚節(jié)點，比如10個，即參數(shù)配置為node.master: false ，node.data: false；小規(guī)模節(jié)點，可以不用如此設置，當然如果依然有性能問題，也是一個優(yōu)化的措施
參考文檔
ElasticSearch性能優(yōu)化策略elasticsearch三個重要的優(yōu)化
ElasticSearch優(yōu)化系列二：機器設置（內存） - 簡書
http://www.itdecent.cn/p/a2b682e5c1ab
預留一半內存給Lucene使用
一個常見的問題是配置堆太大。你有一個64 GB的機器，覺得JVM內存越大越好，想給Elasticsearch所有64 GB的內存。當然，內存對于Elasticsearch來說絕對是重要的，用于更多的內存數(shù)據(jù)提供更快的操作。而且還有一個內存消耗大戶-LuceneLucene的設計目的是把底層OS里的數(shù)據(jù)緩存到內存中。Lucene的段是分別存儲到單個文件中的，這些文件都是不會變化的，所以很利于緩存，同時操作系統(tǒng)也會把這些段文件緩存起來，以便更快的訪問。Lucene的性能取決于和OS的交互，如果你把所有的內存都分配給Elasticsearch，不留一點給Lucene，那你的全文檢索性能會很差的。最后標準的建議是把50%的內存給elasticsearch，剩下的50%也不會沒有用處的，Lucene會很快吞噬剩下的這部分內存。
32GB限制
給ES的內存配置不是越大越好，建議不能超過32GB，不同jdk版本最大邊界值是不同的，對于32位小于32G JVM才采用內存對象指針壓縮技術，不然對象指針需要占用很大的內存使用如下命令測試最大邊界值：
java -Xmx32767m -XX:+PrintFlagsFinal 2> /dev/null | grep UseCompressedOops bool UseCompressedOops = false {lp64_product} java -Xmx32766m -XX:+PrintFlagsFinal 2> /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 | grep UseCompressedOops bool UseCompressedOops := true$ JAVA_HOME=/usr/libexec/java_home -v 1.8 java -Xmx32767m -XX:+PrintFlagsFinal 2> /dev/null | grep UseCompressedOops bool UseCompressedOops = false
在ES啟動日志中最好能夠看到壓縮對象指針為真。heap size [15.8gb], compressed ordinary object pointers [true]在java中，所有的對象都分配在堆上，然后有一個指針引用它。指向這些對象的指針大小通常是CPU的字長的大小，不是32bit就是64bit，這取決于你的處理器，指針指向了你的值的精確位置。對于32位系統(tǒng)，你的內存最大可使用4G。對于64系統(tǒng)可以使用更大的內存。但是64位的指針意味著更大的浪費，因為你的指針本身大了。浪費內存不算，更糟糕的是，更大的指針在主內存和緩存器（例如LLC, L1等）之間移動數(shù)據(jù)的時候，會占用更多的帶寬。java 使用一個叫內存指針壓縮的技術來解決這個問題。它的指針不再表示對象在內存中的精確位置，而是表示偏移量。這意味著32位的指針可以引用40億個對象，而不是40億個字節(jié)。最終，也就是說堆內存長到32G的物理內存，也可以用32bit的指針表示。一旦你越過那個神奇的30-32G的邊界，指針就會切回普通對象的指針，每個對象的指針都變長了，就會使用更多的CPU內存帶寬，也就是說你實際上失去了更多的內存。事實上當內存到達40-50GB的時候，有效內存才相當于使用內存對象指針壓縮技術時候的32G內存。這段描述的意思就是說：即便你有足夠的內存，也盡量不要超過32G，因為它浪費了內存，降低了CPU的性能，還要讓GC應對大內存。
機器內存大于64GB
你可以考慮一臺機器上創(chuàng)建兩個或者更多ES節(jié)點，而不要部署一個使用32+GB內存的節(jié)點。仍然要 堅持50%原則，假設 你有個機器有128G內存，你可以創(chuàng)建兩個node，使用32G內存。也就是說64G內存給ES的堆內存，剩下的64G給Lucene。如果你選擇第二種，你需要配置cluster.routing.allocation.same_shard.host:true
。這會防止同一個shard的主副本存在同一個物理機上（因為如果存在一個機器上，副本的高可用性就沒有了）
swapping是性能的墳墓
這是顯而易見的，但是還是有必要說的更清楚一點，內存交換到磁盤對服務器性能來說是致命的。想想看一個內存的操作必須是快速的。如果內存交換到磁盤上，一個100微秒的操作可能變成10毫秒，再想想那么多10微秒的操作時延累加起來。不難看出swapping對于性能是多么可怕。最好的辦法就是在你的操作系統(tǒng)中完全禁用swapping。這樣可以暫時禁用：sudo swapoff -a
為了永久禁用它，你可能需要修改/etc/fstab文件，這要參考你的操作系統(tǒng)相關文檔。如果完全禁用swap，對你來說是不可行的。你可以降低swappiness 的值，這個值決定操作系統(tǒng)交換內存的頻率。這可以預防正常情況下發(fā)生交換。但仍允許os在緊急情況下發(fā)生交換。對于大部分Linux操作系統(tǒng)，可以在sysctl 中這樣配置：vm.swappiness = 1
備注：swappiness設置為1比設置為0要好，因為在一些內核版本，swappness=0會引發(fā)OOM（內存溢出）最后，如果上面的方法都不能做到，你需要打開配置文件中的mlockall開關，它的作用就是運行JVM鎖住內存，禁止OS交換出去。在elasticsearch.yml配置如下：bootstrap.mlockall: true
未完待續(xù)
ElasticSearch優(yōu)化系列三：機器設置（內存） - 簡書
http://www.itdecent.cn/p/59acd190aa41
heap參數(shù)設置優(yōu)化
命令行修改
./bin/elasticsearch -Xmx10g -Xms10g
xmx-JVM最大允許分配的堆內存，按需分配
xms-JVM初始分配的堆內存
此值設置與-Xmx相同，以避免每次垃圾回收完成后JVM重新分配內存。
對Unix系統(tǒng)，可修改./bin/elasticsearch.in.sh文件：
一般分配主機1/4-1/2的內存
if [ "x$ES_MIN_MEM" ="x" ]; thenES_MIN_MEM=12gfi if [ "x$ES_MAX_MEM" ="x" ]; then ES_MAX_MEM=12gfi JAVA_OPTS="$JAVA_OPTS-Xms${ES_MIN_MEM}"JAVA_OPTS="$JAVA_OPTS -Xmx${ES_MAX_MEM}"
線程大小, ES單線程承載的數(shù)據(jù)量比較大JAVA_OPTS="$JAVA_OPTS -Xss128m"
測試常用設置
內存文件系統(tǒng)
將ES的數(shù)據(jù)目錄放到內存文件系統(tǒng)（屏蔽磁盤I/O瓶頸，內存文件系統(tǒng)寫入速度能達到1GB/S以上）mount -t tmpfs -o size=10G,mode=0755 tmpfs /home/elasticsearch-2.3.1/data
操作系統(tǒng)環(huán)境調節(jié)
ulimit -n 65536ulimit -l unlimitedulimit -s unlimited
壓力測試工具
jmeterBenchmarking elasticsearch with Apache JMeter
未完待續(xù)
ElasticSearch優(yōu)化系列四：ES的heap是如何被瓜分掉的 - 簡書
http://www.itdecent.cn/p/f41b706db6c7
以下分別解讀幾個我知道的內存消耗大戶：
Segment MemorySegment不是file嗎？segment memory又是什么？前面提到過，一個segment是一個完備的lucene倒排索引，而倒排索引是通過詞典(Term Dictionary)到文檔列表(Postings List)的映射關系，快速做查詢的。由于詞典的size會很大，全部裝載到heap里不現(xiàn)實，因此Lucene為詞典做了一層前綴索引(Term Index)，這個索引在Lucene4.0以后采用的數(shù)據(jù)結構是FST (Finite StateTransducer)。這種數(shù)據(jù)結構占用空間很小，Lucene打開索引的時候將其全量裝載到內存中，加快磁盤上詞典查詢速度的同時減少隨機磁盤訪問次數(shù)。下面是詞典索引和詞典主存儲之間的一個對應關系圖:
說了這么多，要傳達的一個意思就是，ES的data node存儲數(shù)據(jù)并非只是耗費磁盤空間的，為了加速數(shù)據(jù)的訪問，每個segment都有會一些索引數(shù)據(jù)駐留在heap里。因此segment越多，瓜分掉的heap也越多，并且這部分heap是無法被GC掉的！ 理解這點對于監(jiān)控和管理集群容量很重要，當一個node的segment memory占用過多的時候，就需要考慮刪除、歸檔數(shù)據(jù)，或者擴容了。
怎么知道segment memory占用情況呢? CAT API可以給出答案。
查看一個索引所有segment的memory占用情況：
查看一個node上所有segment占用的memory總和:
那么有哪些途徑減少data node上的segment memory占用呢？總結起來有三種方法：
刪除不用的索引。
關閉索引（文件仍然存在于磁盤，只是釋放掉內存）。需要的時候可以重新打開。
定期對不再更新的索引做optimize (ES2.0以后更改為force merge api)。這Optimze的實質是對segment file強制做合并，可以節(jié)省大量的segment memory。
Filter CacheFilter cache是用來緩存使用過的filter的結果集的，需要注意的是這個緩存也是常駐heap，無法GC的。默認的10% heap size設置工作得夠好了，如果實際使用中heap沒什么壓力的情況下，才考慮加大這個設置。
Field Data cache對搜索結果做排序或者聚合操作，需要將倒排索引里的數(shù)據(jù)進行解析，然后進行一次倒排。在有大量排序、數(shù)據(jù)聚合的應用場景，可以說field data cache是性能和穩(wěn)定性的殺手。這個過程非常耗費時間，因此ES2.0以前的版本主要依賴這個cache緩存已經計算過的數(shù)據(jù)，提升性能。但是由于heap空間有限，當遇到用戶對海量數(shù)據(jù)做計算的時候，就很容易導致heap吃緊，集群頻繁GC，根本無法完成計算過程。ES2.0以后，正式默認啟用Doc Values特性(1.x需要手動更改mapping開啟)，將field data在indexing time構建在磁盤上，經過一系列優(yōu)化，可以達到比之前采用field data cache機制更好的性能。因此需要限制對field data cache的使用，最好是完全不用，可以極大釋放heap壓力。這里需要注意的是，排序、聚合字段必須為not analyzed。設想如果有一個字段是analyzed過的，排序的實際對象其實是詞典，在數(shù)據(jù)量很大情況下這種情況非常致命。
Bulk QueueBulk Queue是做什么用的？當所有的bulk thread都在忙，無法響應新的bulk request的時候，將request在內存里排列起來，然后慢慢清掉。一般來說，Bulk queue不會消耗很多的heap，但是見過一些用戶為了提高bulk的速度，客戶端設置了很大的并發(fā)量，并且將bulk Queue設置到不可思議的大，比如好幾千。這在應對短暫的請求爆發(fā)的時候有用，但是如果集群本身索引速度一直跟不上，設置的好幾千的queue都滿了會是什么狀況呢？ 取決于一個bulk的數(shù)據(jù)量大小，乘上queue的大小，heap很有可能就不夠用，內存溢出了。一般來說官方默認的threadpool設置已經能很好的工作了，建議不要隨意去“調優(yōu)”相關的設置，很多時候都是適得其反的效果。
Indexing BufferIndexing Buffer是用來緩存新數(shù)據(jù)，當其滿了或者refresh/flush interval到了，就會以segment file的形式寫入到磁盤。這個參數(shù)的默認值是10% heap size。根據(jù)經驗，這個默認值也能夠很好的工作，應對很大的索引吞吐量。但有些用戶認為這個buffer越大吞吐量越高，因此見過有用戶將其設置為40%的。到了極端的情況，寫入速度很高的時候，40%都被占用，導致OOM。Cluster State BufferES被設計成每個Node都可以響應用戶的api請求，因此每個Node的內存里都包含有一份集群狀態(tài)的拷貝。這個Cluster state包含諸如集群有多少個Node，多少個index，每個index的mapping是什么？有少shard，每個shard的分配情況等等(ES有各類stats api獲取這類數(shù)據(jù))。在一個規(guī)模很大的集群，這個狀態(tài)信息可能會非常大的，耗用的內存空間就不可忽視了。并且在ES2.0之前的版本，state的更新是由Master Node做完以后全量散播到其他結點的。頻繁的狀態(tài)更新都有可能給heap帶來壓力。在超大規(guī)模集群的情況下，可以考慮分集群并通過tribe node連接做到對用戶api的透明，這樣可以保證每個集群里的state信息不會膨脹得過大。
超大搜索聚合結果集的fetchES是分布式搜索引擎，搜索和聚合計算除了在各個data node并行計算以外，還需要將結果返回給匯總節(jié)點進行匯總和排序后再返回。無論是搜索，還是聚合，如果返回結果的size設置過大，都會給heap造成很大的壓力，特別是數(shù)據(jù)匯聚節(jié)點。
未完待續(xù)
ElasticSearch優(yōu)化系列五：機器設置（硬盤、CPU） - 簡書
http://www.itdecent.cn/p/919f191acc94
硬盤對集群非常重要，特別是建索引多的情況。磁盤是一個服務器最慢的系統(tǒng)，對于寫比較重的集群，磁盤很容易成為集群的瓶頸。如果可以承擔的器SSD盤，最好使用SSD盤。如果使用SSD，最好調整I/O調度算法。RAID0是加快速度的不錯方法。ES建議機器配置：64G內存 SSD硬盤 RAID0，不要使用NAS。
自動調整存儲帶寬
在2.0.0之前，elasticsearch會限制合并速度（merges），默認為20MB/sec。但是這個速率經常是顯得太小，導致合并速度落后于索引速度，進而限制了索引速度。
現(xiàn)在Elasticsearch2.0.0，使用了自動調整合并IO速度方式：如果合并落于索引速度，合并IO速度會逐漸增大，并且隨著合并的持續(xù)進行會減小。在索引吞吐量小的時候，即使突然來了一個大的合并任務，這種情況也不會吞噬整個節(jié)點可用的IO，極小化的降低對正在進行的查詢和索引的影響。
但是對索引請求大的情況下，允許的合并速度會自動調整到跟上索引的速度。
有了2.0.0這個特性，意味著我們不需要管任何的限制值了，只要用默認的就好了。
2.0.0之前store throttle 設置值有如下幾個，在2.0.0版本已經刪除了。
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 仍然是有速度限制的，默認都是20MB/sec。
多個path.data 路徑
如果磁盤空間和IO性能是Elasticsearch的瓶頸的話，使用多個IO設備（通過設置多個path.data路徑）存儲shards，能夠增加總的存儲空間和提升IO性能。在Elasticsearch2.0之前的版本，也是配置多個path.data路徑，但是其相當于RAID 0，每個shards的數(shù)據(jù)會分布在所有的磁盤上。當一個節(jié)點上有一塊盤壞了的情況下，該節(jié)點上所有的shards都會損壞了。需要恢復該節(jié)點上的所有shards。在2.0.0版本，把這個實現(xiàn)改成了：每個shards所有的數(shù)據(jù)只會在一塊磁盤上面。這樣即使一個節(jié)點的一塊磁盤損壞了，也只是損失了該磁盤上的shards，其它磁盤上的shards安然無事。只需要恢復該塊盤上的shards即可。升級到2.0.0版本時，舊版本一個shard分布到所有磁盤上的數(shù)據(jù)，會拷貝到一塊盤上。對應這個改變，在設計shards時，如果一個節(jié)點有10塊磁盤，共3個節(jié)點，則shards至少30個，才能分布在30塊盤上（即最大限度使用磁盤空間）。參考https://www.elastic.co/blog/performance-indexing-2.0https://www.elastic.co/guide/en/elasticsearch/guide/current/hardware.html
CPU（threadpool）
線程不是越大越好，一般設置threadpool數(shù)為CPU cores的個數(shù)搜索：int((# of cores * 3) / 2) + 1
ElastiSearch服務器有多個線程池大小配置。主要有：index，search，suggest，get，bulk，percolate，snapshot，snapshot_data，warmer，refresh。在此主要針對index和search進行一個配置調整。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
未完待續(xù)
ElasticSearch優(yōu)化系列六：索引過程 - 簡書
http://www.itdecent.cn/p/b4eda49583b5
大家可能會遇到索引數(shù)據(jù)比較慢的過程。其實明白索引的原理就可以有針對性的進行優(yōu)化。ES索引的過程到相對Lucene的索引過程多了分布式數(shù)據(jù)的擴展，而這ES主要是用tranlog進行各節(jié)點之間的數(shù)據(jù)平衡。所以從上我可以通過索引的settings進行第一優(yōu)化："index.translog.flush_threshold_ops":"10000" "refresh_interval" : "1s"
這兩個參數(shù)第一是到translog數(shù)據(jù)達到多少條進行平衡，默認為5000，而這個過程相對而言是比較浪費時間和資源的。所以我們可以將這個值調大一些還是設為-1關閉，進而手動進行translog平衡。第二參數(shù)是刷新頻率，默認為1s是指索引在生命周期內定時刷新，一但有數(shù)據(jù)進來能refresh像lucene里面commit,我們知道當數(shù)據(jù)addDoucment后，還不能檢索到要commit之后才能行數(shù)據(jù)的檢索，所以可以將其關閉，在最初索引完后手動refresh之，然后將索引setting里面的index.refresh_interval參數(shù)按需求進行修改，從而可以提高索引過程效率。
另外的知道ES索引過程中如果有副本存在，數(shù)據(jù)也會馬上同步到副本中去。我個人建議在索引過程中將副本數(shù)設為0，待索引完成后將副本數(shù)按需量改回來，這樣也可以提高索引效率?！皀umber_of_replicas”: 0
其實檢索速度快度與索引質量有很大的關系。而索引質量的好壞主要與以下幾方面有關：
分片數(shù)
分片數(shù)是與檢索速度非常相關的的指標，如果分片數(shù)過少或過多都會導致檢索比較慢。分片數(shù)過多會導致檢索時打開比較多的文件別外也會導致多臺服務器之間通訊。而分片數(shù)過少會導致單個分片索引過大，所以檢索速度慢?；谒饕制瑪?shù)=數(shù)據(jù)總量/單分片數(shù)的計算公式，在確定分片數(shù)之前需要進行單服務單索引單分片的測試，目前我們測試的結果單個分片的內容為10G。
分片（Shard）：一個索引會分成多個分片存儲，分片數(shù)量在索引建立后不可更改，推薦【分片數(shù)*副本數(shù)=集群數(shù)量】
確定分片(shard)的數(shù)量和副本(replica)的數(shù)量
ElasticSearch在創(chuàng)建索引數(shù)據(jù)時，最好指定相關的shards數(shù)量和replicas， 否則會使用服務器中的默認配置參數(shù)shards=5，replicas=1
。因為這兩個屬性的設置直接影響集群中索引和搜索操作的執(zhí)行。假設你有足夠的機器來持有碎片和副本，那么可以按如下規(guī)則設置這兩個值：1) 擁有更多的碎片可以提升索引執(zhí)行能力，并允許通過機器分發(fā)一個大型的索引；2) 擁有更多的副本能夠提升搜索執(zhí)行能力以及集群能力。對于一個索引來說，number_of_shards只能設置一次，而number_of_replicas可以使用索引更新設置API在任何時候被增加或者減少。這兩個配置參數(shù)在配置文件的配置如下：index.number_of_shards: 5 number_of_replicas: 1
Elastic官方文檔建議：一個Node中一個索引最好不要多于三個shards.配置total_shards_per_node參數(shù)，限制每個index每個節(jié)點最多分配多少個發(fā)片.
http://www.open-open.com/doc/view/f240d61f8f7745098b4459c2483feb40
http://wenku.baidu.com/link?url=bwD9mpebmQ28mqPj6Z0P1_A9bgFKnhIss8UrRA_Nsv7oTFuUEa9JgUdr9ynKc8OjWvd0pVLsp3tYZTFaNcxVt30EyFBCvkNflFGjMWcqsRq
副本數(shù)
副本數(shù)與索引的穩(wěn)定性有比較大的關系，如果Node在非正常掛了，經常會導致分片丟失，為了保證這些數(shù)據(jù)的完整性，可以通過副本來解決這個問題。建議在建完索引后在執(zhí)行Optimize后，馬上將副本數(shù)調整過來。
分詞
分詞對于索引的影響可大可小，看自己把握。大家或許認為詞庫越多，分詞效果越好，索引質量越好，其實不然。分詞有很多算法，大部分基于詞表進行分詞。也就是說詞表的大小決定索引大小。所以分詞與索引膨漲率有直接關系。詞表不應很多，而對文檔相關特征性較強的即可。比如論文的數(shù)據(jù)進行建索引，分詞的詞表與論文的特征越相似，詞表數(shù)量越小，在保證查全查準的情況下，索引的大小可以減少很多。索引大小減少了，那么檢索速度也就提高了。
索引段
索引段即lucene中的segments概念，我們知道ES索引過程中會refresh和tranlog也就是說我們在索引過程中segments number不只一個。而segments number與檢索是有直接聯(lián)系的，segments number越多檢索越慢，而將segments numbers 有可能的情況下保證為1，這將可以提高將近一半的檢索速度。
https://www.elastic.co/guide/en/elasticsearch/guide/current/hardware.html
未完待續(xù)
ElasticSearch優(yōu)化系列七：優(yōu)化建議 - 簡書
http://www.itdecent.cn/p/29ffce0850af
盡量運行在Sun/Oracle JDK1.7以上環(huán)境中，低版本的jdk容易出現(xiàn)莫名的bug，ES性能體現(xiàn)在在分布式計算中，一個節(jié)點是不足以測試出其性能，一個生產系統(tǒng)至少在三個節(jié)點以上。
ES集群節(jié)點規(guī)劃良好，master、node、client分離開來，data節(jié)點關閉http功能。
合理利用內存。
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=12gfiif [ "x$ES_MAX_MEM" ="x" ]; then ES_MAX_MEM=12gfiJAVA_OPTS="$JAVA_OPTS-Xms${ES_MIN_MEM}"JAVA_OPTS="$JAVA_OPTS-Xmx${ES_MAX_MEM}"
設置每個線程的堆棧大小, ES單線程承載的數(shù)據(jù)量比較大JAVA_OPTS="$JAVA_OPTS -Xss128m"
b) 修改swapping參數(shù)，內存不夠用時才進行swapping（vm.swappiness= 1）c) 暫時不要修改GC方法d）鎖定內存，不讓JVM寫入swapping，避免降低ES的性能bootstrap.mlockall: true
e）緩存類型設置為Soft Reference，只有當內存不夠時才會進行回收index.cache.field.max_size: 50000index.cache.field.expire: 10mindex.cache.field.type: soft
4.權衡建索引的性能和檢索的時效性，修改以下參數(shù)。
“index.translog.flush_threshold_ops”:”10000”“index.refresh_interval”:1“number_of_replicas”: 0
5.倒排詞典的索引需要常駐內存，無法GC，需要監(jiān)控data node上segmentmemory增長趨勢。
定期對不再更新的索引做optimize (ES2.0以后更改為force merge api)。這Optimze的實質是對segment file強制做合并，可以節(jié)省大量的segment memory
6.根據(jù)機器數(shù)，磁盤數(shù)，索引大小等硬件環(huán)境，根據(jù)測試結果，設置最優(yōu)的分片數(shù)和備份數(shù)，單個分片最好不超過10GB，定期刪除不用的索引，做好冷數(shù)據(jù)的遷移。
7.保守配置內存限制參數(shù)，盡量使用doc value存儲以減少內存消耗，查詢時限制size、from參數(shù)。
8.如果不使用_all字段最好關閉這個屬性，否則在創(chuàng)建索引和增大索引大小的時候會使用額外更多的CPU，如果你不受限CPU計算能力可以選擇壓縮文檔的_source。這實際上就是整行日志，所以開啟壓縮可以減小索引大小。
9.避免返回大量結果集的搜索與聚合。缺失需要大量拉取數(shù)據(jù)可以采用scan & scroll api來實現(xiàn)。
10.熟悉各類緩存作用，如field cache, filter cache, indexing cache, bulk queue等等，要設置合理的大小，并且要應該根據(jù)最壞的情況來看heap是否夠用。
11.必須結合實際應用場景，并對集群使用情況做持續(xù)的監(jiān)控。
