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

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

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

? ? "settings" : {

? ? ? ? "index" : {

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

? ? ? ? }

? ? }

}'

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

2.選擇正確的存儲(chǔ)

一般來說因悲，如果運(yùn)行的是64位操作系統(tǒng)堕汞，你應(yīng)該選擇mmapfs。如果沒有運(yùn)行64位操作系統(tǒng)晃琳，為UNIX系統(tǒng)選擇niofs讯检，為Windows系統(tǒng)選擇simplefs。如果你可以容忍一個(gè)易失的存儲(chǔ)卫旱，但希望它非橙俗疲快，可以看看memory存儲(chǔ)顾翼，它會(huì)給你最好的索引訪問性能投放，但需要足夠的內(nèi)存來處理所有索引文件、索引和查詢适贸。

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

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

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

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

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

suggest：此線程池用于建議器請(qǐng)求处硬。它的類型默認(rèn)為fixed小槐，size默認(rèn)為可用處理器的數(shù)量，隊(duì)列的size默認(rèn)為1000荷辕。

get：此線程池用于實(shí)時(shí)的GET請(qǐng)求凿跳。它的類型默認(rèn)為fixed，size默認(rèn)為可用處理器的數(shù)量疮方，隊(duì)列的size默認(rèn)為1000控嗜。

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

percolate：此線程池用于預(yù)匹配器操作承边。它的類型默認(rèn)為fixed，size默認(rèn)為可用處理器的數(shù)量石挂，隊(duì)列的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)癥狀為 對(duì)于大小超過100g的index（5個(gè)分片 1e數(shù)據(jù)量左右）插入超級(jí)慢富岳，由于機(jī)器資源有限 ，只能想出 將每一天的數(shù)據(jù)建立一個(gè)index+“yyyy-MM-dd” 這樣可以有效緩解我們集群的壓力拯腮，有人會(huì)說如果改成這種方案那么之前寫的查詢豈不是廢了窖式，其實(shí)很easy，es支持index通配符 比如你之前是logment ?現(xiàn)在是logment2015-05-01和logment2015-05-02 ?現(xiàn)在只需要將查詢的代碼中index改為 logment* 就ok了 动壤，而且此法便于刪除過期的index 寫一個(gè)定時(shí)任務(wù)就ok了?

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

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

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

這里我不分析cms和g1的細(xì)節(jié)區(qū)別，大內(nèi)存（超過8g）下G1還是很給力的启妹，親測(cè)有效,用了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ù)時(shí)間饶米；2.降低FULLGC 幾率

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

6. 清理掉沒用的緩存

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

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

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

bootstrap.mlockall: true

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

index.cache.field.max_size: 50000

index.cache.field.expire: 10m

index.cache.field.type: soft

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

http://10.22.2.201:9200/*/_cache/clear? //清除所有索引的cache，如果對(duì)查詢有實(shí)時(shí)性要求伊滋，慎用碳却！

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

http://10.22.2.201:9200/*/_optimize