Elasticsearch常常作為日志存儲(chǔ)和分析的工具，在企業(yè)級(jí)應(yīng)用中常常使用。Elasticsearch提供強(qiáng)大的搜索、分析功能，已經(jīng)是后端技術(shù)棧不可缺少的一部分。
創(chuàng)新互聯(lián)公司是一家集網(wǎng)站建設(shè),霍爾果斯企業(yè)網(wǎng)站建設(shè),霍爾果斯品牌網(wǎng)站建設(shè),網(wǎng)站定制,霍爾果斯網(wǎng)站建設(shè)報(bào)價(jià),網(wǎng)絡(luò)營(yíng)銷(xiāo),網(wǎng)絡(luò)優(yōu)化,霍爾果斯網(wǎng)站推廣為一體的創(chuàng)新建站企業(yè)，幫助傳統(tǒng)企業(yè)提升企業(yè)形象加強(qiáng)企業(yè)競(jìng)爭(zhēng)力?？沙浞譂M(mǎn)足這一群體相比中小企業(yè)更為豐富、高端、多元的互聯(lián)網(wǎng)需求。同時(shí)我們時(shí)刻保持專(zhuān)業(yè)、時(shí)尚、前沿，時(shí)刻以成就客戶(hù)成長(zhǎng)自我，堅(jiān)持不斷學(xué)習(xí)、思考、沉淀、凈化自己，讓我們?yōu)楦嗟钠髽I(yè)打造出實(shí)用型網(wǎng)站。
在維護(hù)ElastciSearch集群的時(shí)候，對(duì)Elasticsearch進(jìn)行了一些調(diào)優(yōu)和分析，現(xiàn)整理成文，純屬拙見(jiàn)，如果有不合理之處，歡迎指出探討。我所使用的Elasticsearch版本為5.x。
Elasticsearch有大量的查詢(xún)數(shù)據(jù)和插入數(shù)據(jù)的請(qǐng)求，需要大量文件句柄，centos系統(tǒng)默認(rèn)的1024個(gè)文件句柄。如果文件句柄用完了，這就意味著操作系統(tǒng)會(huì)拒絕連接，意味著數(shù)據(jù)可能丟失，這是災(zāi)難性的后果，
不能被接受。登陸Elasticsearch的啟動(dòng)用戶(hù)，用一下命令查看：
ulimit?-a
查看結(jié)果：
core?file?size?(blocks,?-c)?0 data?seg?size?(kbytes,?-d)?unlimited scheduling?priority?(-e)?0 file?size?(blocks,?-f)?unlimited pending?signals?(-i)?127673 max?locked?memory?(kbytes,?-l)?unlimited max?memory?size?(kbytes,?-m)?unlimited open?files?(-n)?1024 pipe?size?(512?bytes,?-p)?8 POSIX?message?queues?(bytes,?-q)?819200 real-time?priority?(-r)?0 stack?size?(kbytes,?-s)?8192 cpu?time?(seconds,?-t)?unlimited max?user?processes?(-u)?2056474 virtual?memory?(kbytes,?-v)?unlimited file?locks?(-x)?unlimited
上面的文件句柄（open files）的個(gè)數(shù)為1024，在ElasticSearch大量請(qǐng)求的情況下，這個(gè)句柄數(shù)量是不夠的，可以改成655360。
臨時(shí)修改可以通過(guò)執(zhí)行以下命令，即可立即生效，但是機(jī)器重啟后又會(huì)失效：
ulimit?-n?655360
永久生效，修改/etc/security/limits.conf，需要重啟機(jī)器生效：
u_es?-?nofile?655360
上述配置中u_es為啟動(dòng)ElasticSearch的用戶(hù)，設(shè)置了該用戶(hù)的ElasticSearch的文件句柄為655360、
JVM參數(shù)優(yōu)化
Elasticsearch是運(yùn)行在JVM上的，對(duì)其做JVM參數(shù)調(diào)優(yōu)至關(guān)重要。最常見(jiàn)的調(diào)優(yōu)是Java內(nèi)存的分配。下面是JVM的內(nèi)存模型，具體每塊的作用，不在這里闡述。
新生代和老年代分配的內(nèi)存比例給多大？
Jvm內(nèi)存分為新生代和老年代。
新生代（或者伊甸園）
新實(shí)例化的對(duì)象分配的空間。新生代空間通常都非常小，一般在 100 MB–500 MB。新生代也包含兩個(gè) 幸存 空間。
老年代
較老的對(duì)象存儲(chǔ)的空間。這些對(duì)象預(yù)計(jì)將長(zhǎng)期留存并持續(xù)上很長(zhǎng)一段時(shí)間。老生代通常比新生代大很多。
新生代、老生代的垃圾回收都有一個(gè)階段會(huì)“stop the world”。在這段時(shí)間里，JVM 停止了程序運(yùn)行，以便對(duì)對(duì)象進(jìn)行可達(dá)性分析，收集死亡對(duì)象。在這個(gè)時(shí)間停止階段，一切都不會(huì)發(fā)生。請(qǐng)求不被服務(wù)，ping 不被回應(yīng)，分片不被分配。整個(gè)世界都真的停止了。
對(duì)于新生代，這不是什么大問(wèn)題；那么小的空間意味著 GC 會(huì)很快執(zhí)行完。但是老生代大很多，而這里面一個(gè)慢 GC 可能就意味著 1 秒乃至 15 秒的暫停——對(duì)于服務(wù)器軟件來(lái)說(shuō)這是不可接受的。
那一般我們給新生代和老年代分配多大的內(nèi)存呢？他們的比例是多少呢？
一般來(lái)說(shuō)，老年代和新生代的內(nèi)存比例為2：1是比較合適的。比如給堆內(nèi)存分配3G，則新生代分配1G，其余都給老年代。在ElasticSearce的配置文件jvm.options文件配置：
-Xms3g?//配置堆初始化大小 -Xmx3g?//配置堆的最大內(nèi)存 -Xmn1g?//配置新生代內(nèi)存。
該分配多大的內(nèi)存給Elasticesearch？
在使用Elasticesearch的時(shí)候，我們對(duì)裝Elasticesearch的機(jī)器進(jìn)行了升級(jí)，從最小的8G內(nèi)存升級(jí)到了16G內(nèi)存，然后到目前的32G內(nèi)存。一臺(tái)機(jī)器裝一個(gè)Elasticesearch節(jié)點(diǎn)，我們應(yīng)該怎么分配機(jī)器的內(nèi)存呢？
官方給出了解決方案，把一半（少于）的內(nèi)存分配給Luence，另外的內(nèi)存分配給ElasticSearch.
內(nèi)存對(duì)于 Elasticsearch 來(lái)說(shuō)絕對(duì)是重要的，它可以被許多內(nèi)存數(shù)據(jù)結(jié)構(gòu)使用來(lái)提供更快的操作。但是說(shuō)到這里， 還有另外一個(gè)內(nèi)存消耗大戶(hù) 非堆內(nèi)存 （off-heap）：Lucene。
Lucene 被設(shè)計(jì)為可以利用操作系統(tǒng)底層機(jī)制來(lái)緩存內(nèi)存數(shù)據(jù)結(jié)構(gòu)。Lucene 的段是分別存儲(chǔ)到單個(gè)文件中的。因?yàn)槎问遣豢勺兊?，這些文件也都不會(huì)變化，這是對(duì)緩存友好的，同時(shí)操作系統(tǒng)也會(huì)把這些段文件緩存起來(lái)，以便更快的訪問(wèn)。
Lucene 的性能取決于和操作系統(tǒng)的相互作用。如果你把所有的內(nèi)存都分配給 Elasticsearch 的堆內(nèi)存，那將不會(huì)有剩余的內(nèi)存交給 Lucene。這將嚴(yán)重地影響全文檢索的性能。
標(biāo)準(zhǔn)的建議是把 50％ 的可用內(nèi)存作為 Elasticsearch 的堆內(nèi)存，保留剩下的 50％。當(dāng)然它也不會(huì)被浪費(fèi)，Lucene 會(huì)很樂(lè)意利用起余下的內(nèi)存。
我們實(shí)際的解決辦法是將機(jī)器的一半分給Elasticesearch的堆，棧內(nèi)存、方法區(qū)、常量池、非堆內(nèi)存占用另外一半。
分配給堆最大內(nèi)存應(yīng)該小于 32766 mb（~31.99 gb）
JVM 在內(nèi)存小于 32 GB 的時(shí)候會(huì)采用一個(gè)內(nèi)存對(duì)象指針壓縮技術(shù)。
對(duì)于 32 位的系統(tǒng)，意味著堆內(nèi)存大小最大為 4 GB。對(duì)于 64 位的系統(tǒng)， 可以使用更大的內(nèi)存，但是 64 位的指針意味著更大的浪費(fèi)，因?yàn)槟愕闹羔槺旧泶罅?。更糟糕的是?更大的指針在主內(nèi)存和各級(jí)緩存（例如 LLC，L1 等）之間移動(dòng)數(shù)據(jù)的時(shí)候，會(huì)占用更多的帶寬。
Java 使用一個(gè)叫作 內(nèi)存指針壓縮（compressed oops）的技術(shù)來(lái)解決這個(gè)問(wèn)題。它的指針不再表示對(duì)象在內(nèi)存中的精確位置，而是表示 偏移量 。這意味著 32 位的指針可以引用 40 億個(gè) 對(duì)象 ， 而不是 40 億個(gè)字節(jié)。最終， 也就是說(shuō)堆內(nèi)存增長(zhǎng)到 32 GB 的物理內(nèi)存，也可以用 32 位的指針表示。
一旦你越過(guò)那個(gè)神奇的 ~32 GB 的邊界，指針就會(huì)切回普通對(duì)象的指針。每個(gè)對(duì)象的指針都變長(zhǎng)了，就會(huì)使用更多的 CPU 內(nèi)存帶寬，也就是說(shuō)你實(shí)際上失去了更多的內(nèi)存。事實(shí)上，當(dāng)內(nèi)存到達(dá) 40–50 GB 的時(shí)候，有效內(nèi)存才相當(dāng)于使用內(nèi)存對(duì)象指針壓縮技術(shù)時(shí)候的 32 GB 內(nèi)存。
這段描述的意思就是說(shuō)：即便你有足夠的內(nèi)存，也盡量不要 超過(guò) 32 GB。因?yàn)樗速M(fèi)了內(nèi)存，降低了 CPU 的性能，還要讓 GC 應(yīng)對(duì)大內(nèi)存。
關(guān)掉swap
內(nèi)存交換 到磁盤(pán)對(duì)服務(wù)器性能來(lái)說(shuō)是 致命 的。
如果內(nèi)存交換到磁盤(pán)上，一個(gè) 100 微秒的操作可能變成 10 毫秒。再想想那么多 10 微秒的操作時(shí)延累加起來(lái)。不難看出 swapping 對(duì)于性能是多么可怕。
用以下命令關(guān)掉swap:
sudo?swapoff?-a
不要碰以下的配置
所有的調(diào)整就是為了優(yōu)化，但是這些調(diào)整，你真的不需要理會(huì)它。因?yàn)樗鼈兘?jīng)常會(huì)被亂用，從而造成系統(tǒng)的不穩(wěn)定或者糟糕的性能，甚至兩者都有可能。
線程池配置
許多人 喜歡 調(diào)整線程池。無(wú)論什么原因，人們都對(duì)增加線程數(shù)無(wú)法抵抗。索引太多了？增加線程！搜索太多了？增加線程！節(jié)點(diǎn)空閑率低于 95％？增加線程！
Elasticsearch 默認(rèn)的線程設(shè)置已經(jīng)是很合理的了。對(duì)于所有的線程池（除了 搜索 ），線程個(gè)數(shù)是根據(jù) CPU 核心數(shù)設(shè)置的。如果你有 8 個(gè)核，你可以同時(shí)運(yùn)行的只有 8 個(gè)線程，只分配 8 個(gè)線程給任何特定的線程池是有道理的。
搜索線程池設(shè)置的大一點(diǎn)，配置為 int（（ 核心數(shù) ＊ 3 ）／ 2 ）＋ 1 。
垃圾回收器
Elasticsearch 默認(rèn)的垃圾回收器（ GC ）是 CMS。這個(gè)垃圾回收器可以和應(yīng)用并行處理，以便它可以最小化停頓。然而，它有兩個(gè) stop-the-world 階段，處理大內(nèi)存也有點(diǎn)吃力。
盡管有這些缺點(diǎn)，它還是目前對(duì)于像 Elasticsearch 這樣低延遲需求軟件的最佳垃圾回收器。官方建議使用 CMS。
合理設(shè)置最小主節(jié)點(diǎn)
minimum_master_nodes 設(shè)置及其重要，為了防止集群腦裂，這個(gè)參數(shù)應(yīng)該設(shè)置為法定個(gè)數(shù)就是 ( master 候選節(jié)點(diǎn)個(gè)數(shù) / 2) + 1。
分片均勻，磁盤(pán)優(yōu)化，剔除掉高負(fù)載的Master競(jìng)選？
筆者在實(shí)際生產(chǎn)環(huán)境中遇到了有一個(gè)節(jié)點(diǎn)的負(fù)載是其他節(jié)點(diǎn)的幾倍，從虛擬機(jī)監(jiān)控上看，所有的節(jié)點(diǎn)的qps是差不多的。機(jī)器的配置是一樣的，為什么負(fù)載會(huì)有如此大的差距？
首先，我們懷疑數(shù)據(jù)分配不均勻，我們排查了下，沒(méi)有這種現(xiàn)象。
然后，我們監(jiān)控到了高負(fù)載的節(jié)點(diǎn)磁盤(pán)IO非常的高，經(jīng)常達(dá)到100%，我們懷疑是那個(gè)虛擬機(jī)磁盤(pán)性能不行。但是我們當(dāng)時(shí)沒(méi)有更好的磁盤(pán)。
我們找到了一個(gè)適中的解決辦法是將這臺(tái)高負(fù)載的節(jié)點(diǎn)剔除Master競(jìng)選，即將elasticsearch.yml文件中的node.master改為false然后重啟，負(fù)載下降了一些。
數(shù)據(jù)存儲(chǔ)天數(shù)的優(yōu)化
存儲(chǔ)天數(shù)的優(yōu)化，這個(gè)需要根據(jù)實(shí)際的業(yè)務(wù)來(lái)，下面是刪除過(guò)期數(shù)據(jù)的腳本，該腳本來(lái)源于https://stackoverflow.com/questions/33430055/removing-old-indices-in-elasticsearch#answer-39746705 ；
重慶分公司
重慶分公司
#!/bin/bash
searchIndex=logstash-monitor
elastic_url=logging.core.k94.kvk.nl
elastic_port=9200
date2stamp?()?{
?date?--utc?--date?"$1"?+%s
}
dateDiff?(){
?case?$1?in
?-s)?sec=1;?shift;;
?-m)?sec=60;?shift;;
?-h)?sec=3600;?shift;;
?-d)?sec=86400;?shift;;
?*)?sec=86400;;
?esac
?dte1=$(date2stamp?$1)
?dte2=$(date2stamp?$2)
?diffSec=$((dte2-dte1))
?if?((diffSec?然后使用crontab每天定時(shí)執(zhí)行一次這個(gè)腳本。
集群分片設(shè)置
ES一旦創(chuàng)建好索引后，就無(wú)法調(diào)整分片的設(shè)置，而在ES中，一個(gè)分片實(shí)際上對(duì)應(yīng)一個(gè)lucene 索引，而lucene索引的讀寫(xiě)會(huì)占用很多的系統(tǒng)資源，因此，分片數(shù)不能設(shè)置過(guò)大；所以，在創(chuàng)建索引時(shí)，合理配置分片數(shù)是非常重要的。一般來(lái)說(shuō)，我們遵循一些原則：
控制每個(gè)分片占用的硬盤(pán)容量不超過(guò)ES的最大JVM的堆空間設(shè)置（一般設(shè)置不超過(guò)32G，參加上文的JVM設(shè)置原則），因此，如果索引的總?cè)萘吭?00G左右，那分片大小在16個(gè)左右即可；當(dāng)然，最好同時(shí)考慮原則2。
考慮一下node數(shù)量，一般一個(gè)節(jié)點(diǎn)有時(shí)候就是一臺(tái)物理機(jī)，如果分片數(shù)過(guò)多，大大超過(guò)了節(jié)點(diǎn)數(shù)，很可能會(huì)導(dǎo)致一個(gè)節(jié)點(diǎn)上存在多個(gè)分片，一旦該節(jié)點(diǎn)故障，即使保持了1個(gè)以上的副本，同樣有可能會(huì)導(dǎo)致數(shù)據(jù)丟失，集群無(wú)法恢復(fù)。所以， 一般都設(shè)置分片數(shù)不超過(guò)節(jié)點(diǎn)數(shù)的3倍。
索引優(yōu)化
1.修改index_buffer_size 的設(shè)置，可以設(shè)置成百分?jǐn)?shù)，也可設(shè)置成具體的大小，大小可根據(jù)集群的規(guī)模做不同的設(shè)置測(cè)試。
indices.memory.index_buffer_size：10%（默認(rèn)）
indices.memory.min_index_buffer_size：48mb（默認(rèn)）
indices.memory.max_index_buffer_size
_id字段的使用，應(yīng)盡可能避免自定義_id, 以避免針對(duì)ID的版本管理；建議使用ES的默認(rèn)ID生成策略或使用數(shù)字類(lèi)型ID做為主鍵。
_all字段及_source字段的使用，應(yīng)該注意場(chǎng)景和需要，_all字段包含了所有的索引字段，方便做全文檢索，如果無(wú)此需求，可以禁用；_source存儲(chǔ)了原始的document內(nèi)容，如果沒(méi)有獲取原始文檔數(shù)據(jù)的需求，可通過(guò)設(shè)置includes、excludes 屬性來(lái)定義放入_source的字段。
合理的配置使用index屬性，analyzed 和not_analyzed，根據(jù)業(yè)務(wù)需求來(lái)控制字段是否分詞或不分詞。只有 groupby需求的字段，配置時(shí)就設(shè)置成not_analyzed, 以提高查詢(xún)或聚類(lèi)的效率。
查詢(xún)優(yōu)化
查詢(xún)優(yōu)化，調(diào)整filter過(guò)濾順序
如果把過(guò)濾效果不明顯的條件放在了前面，導(dǎo)致查詢(xún)出大量不需要的數(shù)據(jù)，導(dǎo)致查詢(xún)變慢。
把過(guò)濾效果明顯的條件提前，按照過(guò)濾效果把過(guò)濾條件排序
索引時(shí)間精度優(yōu)化
研究Filter的工作原理可以看出，它每次工作都是遍歷整個(gè)索引的，所以時(shí)間粒度越大，對(duì)比越快，搜索時(shí)間越短，在不影響功能的情況下，時(shí)間精度越低越好，有時(shí)甚至犧牲一點(diǎn)精度也值得，當(dāng)然最好的情況是根本不作時(shí)間限制。
es重新刷索引，增加冗余的時(shí)間字段，精確到天。帶有時(shí)間范圍的查詢(xún)使用該字段進(jìn)行查詢(xún)
查詢(xún)Fetch Source優(yōu)化
業(yè)務(wù)查詢(xún)語(yǔ)句獲取的數(shù)據(jù)集比較大，并且從source中獲取了非必須的字段，導(dǎo)致查詢(xún)較慢。
舉例：只需要從es中查詢(xún)id這一個(gè)字段，卻把所有字段查詢(xún)了出來(lái)
預(yù)索引數(shù)據(jù)
利用索引查詢(xún)數(shù)據(jù)是最優(yōu)的方式。例如，如果所有的文檔都有 price 字段，并且大多數(shù)查詢(xún)都在一個(gè)固定的范圍列表中運(yùn)行范圍聚合，那么可以通過(guò)將 index 預(yù)索引到 index 和使用 terms 聚合來(lái)更快地實(shí)現(xiàn)聚合。
例如，像下面這樣：
PUT?index/type/1
{
?"designation":?"spoon",
?"price":?13
}像這樣的查詢(xún)：
GET?index/_search
{
?"aggs":?{
?"price_ranges":?{
?"range":?{
?"field":?"price",
?"ranges":?[
?{?"to":?10?},
?{?"from":?10,?"to":?100?},
?{?"from":?100?}
?]
?}
?}
?}
}文檔在索引的時(shí)候要使用 price_range ，應(yīng)該被映射為關(guān)鍵詞：
PUT?index
{
?"mappings":?{
?"type":?{
?"properties":?{
?"price_range":?{
?"type":?"keyword"
?}
?}
?}
?}
}
PUT?index/type/1
{
?"designation":?"spoon",
?"price":?13,
?"price_range":?"10-100"
}然后這個(gè)請(qǐng)求就直接聚合新字段，而不是在 price 字段運(yùn)行范圍查詢(xún)：
GET?index/_search
{
?"aggs":?{
?"price_ranges":?{
?"terms":?{
?"field":?"price_range"
?}
?}
?}
}總結(jié)
總的來(lái)說(shuō)，ElasticSearch的優(yōu)化，優(yōu)化可以從以下方面的考慮：
硬件的優(yōu)化：機(jī)器分配，機(jī)器配置，機(jī)器內(nèi)存，機(jī)器CPU，機(jī)器網(wǎng)絡(luò)，機(jī)器磁盤(pán)性能
操作系統(tǒng)設(shè)置優(yōu)化：文件句柄優(yōu)化、swap關(guān)閉
ElasticSearch合理分配節(jié)點(diǎn)，合理分配參加競(jìng)選Master的節(jié)點(diǎn)
ElasticSearch的存儲(chǔ)的優(yōu)化，副本數(shù)量、索引數(shù)量、分片數(shù)量
ElasticSearch的使用優(yōu)化，索引的優(yōu)化，查詢(xún)的優(yōu)化
?最后，分享一份面試寶典《Java核心知識(shí)點(diǎn)整理.pdf》，覆蓋了JVM、鎖、高并發(fā)、反射、Spring原理、微服務(wù)、Zookeeper、數(shù)據(jù)庫(kù)、數(shù)據(jù)結(jié)構(gòu)等等
有需要的朋友可以加入Java架構(gòu)技術(shù)交流Q群328993819交流、探討、
