所有的修改都可以在elasticsearch.yml里面修改，也可以通過api來修改。推薦用api比較靈活

1.不同分片之間的數(shù)據(jù)同步是一個很大的花費，默認(rèn)是1s同步，如果我們不要求實時性，我們可以執(zhí)行如下:

$ curl -XPUT 'http://localhost:9200/twitter/' -d '{

? ? "settings" : {

? ? ? ? "index" : {

? ? ? ? "refresh_interval":"60s"

? ? ? ? }

? ? }

}'

?此處我們是修改為60s 其實可以改為-1s ?這樣就是不刷新，我們需要在查詢的時候進行一次索引刷新然后再查詢，這個嘛就得看你們用戶能容忍多少時間長度了。

2.選擇正確的存儲

一般來說，如果運行的是64位操作系統(tǒng)，你應(yīng)該選擇mmapfs。如果沒有運行64位操作系統(tǒng)，為UNIX系統(tǒng)選擇niofs，為Windows系統(tǒng)選擇simplefs。如果你可以容忍一個易失的存儲，但希望它非?？?，可以看看memory存儲，它會給你最好的索引訪問性能，但需要足夠的內(nèi)存來處理所有索引文件、索引和查詢。

3.優(yōu)化es的線程池?

cache：這是無限制的線程池，為每個傳入的請求創(chuàng)建一個線程。

fixed：這是一個有著固定大小的線程池，大小由size屬性指定，允許你指定一個隊列（使用queue_size屬性指定）用來保存請求，直到有一個空閑的線程來執(zhí)行請求。如果Elasticsearch無法把請求放到隊列中（隊列滿了），該請求將被拒絕。有很多線程池（可以使用type屬性指定要配置的線程類型），然而，對于性能來說，最重要的是下面幾個。

index：此線程池用于索引和刪除操作。它的類型默認(rèn)為fixed，size默認(rèn)為可用處理器的數(shù)量，隊列的size默認(rèn)為300。

search：此線程池用于搜索和計數(shù)請求。它的類型默認(rèn)為fixed，size默認(rèn)為可用處理器的數(shù)量乘以3，隊列的size默認(rèn)為1000。

suggest：此線程池用于建議器請求。它的類型默認(rèn)為fixed，size默認(rèn)為可用處理器的數(shù)量，隊列的size默認(rèn)為1000。

get：此線程池用于實時的GET請求。它的類型默認(rèn)為fixed，size默認(rèn)為可用處理器的數(shù)量，隊列的size默認(rèn)為1000。

bulk：你可以猜到，此線程池用于批量操作。它的類型默認(rèn)為fixed，size默認(rèn)為可用處理器的數(shù)量，隊列的size默認(rèn)為50。

percolate：此線程池用于預(yù)匹配器操作。它的類型默認(rèn)為fixed，size默認(rèn)為可用處理器的數(shù)量，隊列的size默認(rèn)為1000。

elasticsearch.yml中可以設(shè)置 ：

threadpool.index.type: fixed

threadpool.index.size: 100

threadpool.index.queue_size: 500

curl -XPUT 'localhost:9200/_cluster/settings' -d '{

? ? "transient": {

? ? ? ? "threadpool.index.type": "fixed",

? ? ? ? "threadpool.index.size": 100,

? ? ? ? "threadpool.index.queue_size": 500

? ? }

}'

4.index過于龐大導(dǎo)致es經(jīng)常奔潰

? ? es最近老是掛掉，無緣無故，表現(xiàn)癥狀為 對于大小超過100g的index（5個分片 1e數(shù)據(jù)量左右）插入超級慢，由于機器資源有限 ，只能想出 將每一天的數(shù)據(jù)建立一個index+“yyyy-MM-dd” 這樣可以有效緩解我們集群的壓力，有人會說如果改成這種方案那么之前寫的查詢豈不是廢了，其實很easy，es支持index通配符 比如你之前是logment ?現(xiàn)在是logment2015-05-01和logment2015-05-02 ?現(xiàn)在只需要將查詢的代碼中index改為 logment* 就ok了 ，而且此法便于刪除過期的index 寫一個定時任務(wù)就ok了?

? ? 我們?nèi)罩镜募軜?gòu)是這樣的 logstash(client1) 采集日志到 redis ?然后通過?logstash(client2) 從redis轉(zhuǎn)至 elasticsearch ，logstash寫入elasticsearch的時候默認(rèn)就是按照每天來建立索引的 在其配置文件無需指明 index和type 即可。?

? ? 此處會產(chǎn)生一個問題，就是logstash 自動建立索引的時候是根據(jù)格林尼治時間來建立的 正正比我們的時間 遲了8小時，我們需要在logstash的lib里面找到event.rb ?然后找到?org.joda.time.DateTimeZone.UTC 格林尼治時間 ?改成?org.joda.time.DateTimeZone.getDefault() （獲取本地時間類型 我這邊運行就是中國/上海） 即可 ?話說logstash用的居然是大名鼎鼎的joda 果然是優(yōu)秀程序 。

5. 采用G1垃圾回收機制代替默認(rèn)CMS

這里我不分析cms和g1的細(xì)節(jié)區(qū)別，大內(nèi)存（超過8g）下G1還是很給力的，親測有效,用了G1 一周內(nèi)一次FULLGC 都沒有，哈哈

? ? elasticsearch.in.sh 內(nèi) 將

# Force the JVM to use IPv4 stack

if?[?"x$ES_USE_IPV4"?!=?"x"?]; then

??JAVA_OPTS="$JAVA_OPTS -Djava.net.preferIPv4Stack=true"

fi

JAVA_OPTS="$JAVA_OPTS -XX:+UseParNewGC"

JAVA_OPTS="$JAVA_OPTS -XX:+UseConcMarkSweepGC"

JAVA_OPTS="$JAVA_OPTS -XX:CMSInitiatingOccupancyFraction=75"

JAVA_OPTS="$JAVA_OPTS -XX:+UseCMSInitiatingOccupancyOnly"

　替換為

JAVA_OPTS="$JAVA_OPTS -XX:+UseG1GC"

JAVA_OPTS="$JAVA_OPTS -XX:MaxGCPauseMillis=200"

?? 順便說句JVM調(diào)優(yōu)，調(diào)優(yōu)最主要目標(biāo):1.就是降低 GC 次數(shù)時間；2.降低FULLGC 幾率

? ? ? PS:優(yōu)化代碼比優(yōu)化JVM實在多了

6. 清理掉沒用的緩存

??回憶之前的問題發(fā)現(xiàn)jvm調(diào)優(yōu)對于老年代的回收并沒有很顯著的效果，隨著時間的推移內(nèi)存還是不夠~后來才發(fā)現(xiàn)是es cache的問題

　其實集群建立時我們是可以調(diào)整每隔節(jié)點的緩存比例、類型、者大小的

# 鎖定內(nèi)存，不讓JVM寫入swapping，避免降低ES的性能

bootstrap.mlockall: true

# 緩存類型設(shè)置為Soft Reference，只有當(dāng)內(nèi)存不夠時才會進行回收

index.cache.field.max_size: 50000

index.cache.field.expire: 10m

index.cache.field.type: soft

??但是如果你不想重新配置節(jié)點并且重啟，你可以做一個定時任務(wù)來定時清除cache

http://10.22.2.201:9200/*/_cache/clear? //清除所有索引的cache，如果對查詢有實時性要求，慎用！

到了晚上資源空閑的時候我們還能合并優(yōu)化一下索引

http://10.22.2.201:9200/*/_optimize