一可免、前情提要

1捂寿、version
es 6.4
jdk 8

2酌畜、 先說(shuō)下背景，目前公司使用elk 作為日志收集報(bào)警一條龍服務(wù)谣旁，并且skywalking 的agent采集數(shù)據(jù)也進(jìn)入相同的es集群床佳，目前使用的表現(xiàn)為，隨著數(shù)據(jù)量持續(xù)增大榄审。kibana 有時(shí)候都打不開(kāi)砌们，skywalking查詢(xún)更別提了，而且數(shù)據(jù)不全搁进，發(fā)現(xiàn)很多數(shù)據(jù)存儲(chǔ)失敗浪感。下面就來(lái)跟進(jìn)排查下。

3饼问、簡(jiǎn)單的看下架構(gòu)圖

image.png

概念解析：

• Node（節(jié)點(diǎn)）：?jiǎn)蝹€(gè)的裝有Elasticsearch服務(wù)并且提供故障轉(zhuǎn)移和擴(kuò)展的服務(wù)器篮撑。
• Cluster（集群）：一個(gè)集群就是由一個(gè)或多個(gè)node組織在一起，共同工作匆瓜，共同分享整個(gè)數(shù)據(jù)具有負(fù)載均衡功能的集群。
• Document（文檔）: 一個(gè)文檔是一個(gè)可被索引的基礎(chǔ)信息單元。
• Index（索引）：索引就是一個(gè)擁有幾分相似特征的文檔的集合驮吱。
• Type（類(lèi)型）：一個(gè)索引中茧妒，你可以定義一種或多種類(lèi)型。
• Field（列）： Field是Elasticsearch的最小單位左冬，相當(dāng)于數(shù)據(jù)的某一列桐筏。
• Shards（分片）：Elasticsearch將索引分成若干份，每個(gè)部分就是一個(gè)shard拇砰。
• Replicas （復(fù)制）：Replicas是索引一份或多份拷貝梅忌。

4、影響elasticsearch性能的因素

image.png

二除破、性能優(yōu)化-內(nèi)存篇

入手點(diǎn)很簡(jiǎn)單牧氮，直接看kibana監(jiān)控如下：

image.png

如上圖可以看出吸重，監(jiān)控圖表不連續(xù)啊鲫趁，居然出現(xiàn)很多斷點(diǎn)情況，而且這只是一個(gè)node的監(jiān)控春寿，看整體監(jiān)控的話(huà)會(huì)發(fā)現(xiàn)整個(gè)集群基本處于無(wú)法提供服務(wù)的狀態(tài)（雖然是綠色的）光坝。

通過(guò)JVM heap 會(huì)感覺(jué)出整個(gè)內(nèi)存回收的頻率不對(duì)勁啊最大尸诽，貌似一直在進(jìn)行FULL GC 啊，馬上查看下 gc.log

image.png

果不其然盯另，一直在進(jìn)行FULL GC性含，直接查看es jvm.options 配置

-Xms16g
-Xmx16g
-XX:CMSInitiatingOccupancyFraction=70

結(jié)合上圖會(huì)發(fā)現(xiàn)16G 明顯不夠用嗎，查看了下機(jī)器內(nèi)存發(fā)現(xiàn)居然有128G 鸳惯，嘖嘖商蕴，這么小氣，才給es配置16g悲敷，好吧究恤，整個(gè)簡(jiǎn)單，我來(lái)加大下不就夠用了后德。

在加大這個(gè)內(nèi)存的時(shí)候要注意一點(diǎn)部宿，對(duì)于最大內(nèi)存官方建議是整體內(nèi)存的50%，但是最大不要超過(guò)32G 瓢湃，這里我們?cè)O(shè)置30G理张，原因如下：

因?yàn)樯婕暗揭粋€(gè)JVM OOPS的優(yōu)化策略

• 堆小于4G，無(wú)需編/解碼操作绵患，JVM會(huì)使用低虛擬地址空間（low virutal address space雾叭，64位下模擬32位）
• 小于32G而大于4G，使用Zero Based Compressed OOPS
• 大于32G落蝙，不使用Compressed OOPS

然后繼續(xù)優(yōu)化织狐，將我們的內(nèi)存加大到30

-Xms30g
-Xmx30g

重啟節(jié)點(diǎn)暂幼，如圖：

image.png

誒，貌似內(nèi)存q曲線(xiàn)正常了移迫，非常不錯(cuò)嘛旺嬉，很簡(jiǎn)單嗎，然而并不是這樣厨埋，隨著時(shí)間推移邪媳，內(nèi)存又發(fā)生了變化

image.png

發(fā)現(xiàn)FULL GC 的頻率越來(lái)越快，而且老年代的內(nèi)存基數(shù)越來(lái)越大荡陷，系統(tǒng)隨著時(shí)間推移會(huì)恢復(fù)到頻繁FULL GC 的狀態(tài)雨效，這么看內(nèi)存中有數(shù)據(jù)滯留啊，翻看了下官方文檔發(fā)現(xiàn)幾個(gè)很重要的概念：

• common space
  包括了indexing buffer和其他ES運(yùn)行需要的class废赞。indexing buffer由indices.memory.index_buffer_size參數(shù)控制徽龟， 默認(rèn)最大占用10%，當(dāng)full up后蛹头，該部分?jǐn)?shù)據(jù)被刷入磁盤(pán)對(duì)應(yīng)的Segments中顿肺。這部分空間是可以被回收反復(fù)利用的。

• query cache
  實(shí)例級(jí)別的渣蜗，作用域是node,其按照子Query來(lái)確定是否被Cache屠尊。 Cache的結(jié)果是DocIdSet,可以簡(jiǎn)單理解為布隆過(guò)濾器

• request cache
  shard級(jí)別的緩存，主要緩存size=0的請(qǐng)求耕拷，緩存hits total讼昆，以及aggs等信息

• fielddata cache
  針對(duì)text字段，沒(méi)有docValues屬性(相當(dāng)于列存儲(chǔ))骚烧，當(dāng)對(duì)text類(lèi)型字段進(jìn)行sort,agg時(shí)浸赫，需要將對(duì)應(yīng)的字段內(nèi)容全部加載到內(nèi)存，這部分?jǐn)?shù)據(jù)就放在fieldDataCache赃绊。通過(guò)indices.fielddata.cache.size 參數(shù)限制大小既峡，默認(rèn)不限制。這種情況下碧查，占用內(nèi)存會(huì)逐漸增多运敢，直到觸發(fā)熔斷；新數(shù)據(jù)無(wú)法加載

• segment memory
  緩存段信息忠售，包括FST,Dimensional points for numeric range filters传惠，Deleted documents bitset ，Doc values and stored fields codec formats等數(shù)據(jù)稻扬。這部分緩存是必須的卦方，不能進(jìn)行大小設(shè)置，通常跟index息息相關(guān)泰佳，close index盼砍、force merge均會(huì)釋放部分空間尘吗。 可以通過(guò)命令

GET _cat/nodes?v&h=id,ip,port,r,ramPercent,ramCurrent,heapMax,heapCurrent,fielddataMemory,queryCacheMemory,requestCacheMemory,segmentsMemory

ES 的熔斷策略，ES 本身有對(duì)內(nèi)存的保護(hù)策略浇坐，以防止OOM

• indices.breaker.fielddata.limit fielddata 斷路器默認(rèn)設(shè)置堆的 60% 作為 fielddata 大小的上限摇予。

• indices.breaker.request.limit request 斷路器估算需要完成其他請(qǐng)求部分的結(jié)構(gòu)大小，例如創(chuàng)建一個(gè)聚合桶吗跋，默認(rèn)限制是堆內(nèi)存的 60%。它實(shí)際上是node level的一個(gè)統(tǒng)計(jì)值宁昭，統(tǒng)計(jì)的是這個(gè)結(jié)點(diǎn)上跌宛，各類(lèi)查詢(xún)聚合操作，需要申請(qǐng)的Bigarray的空間大小總和积仗。 所以如果有一個(gè)聚合需要很大的空間疆拘，同時(shí)在執(zhí)行的聚合可能也會(huì)被break掉。

• indices.breaker.total.limit 上面兩個(gè)限制的總開(kāi)關(guān)request(agg)和fielddata不會(huì)使用超過(guò)堆內(nèi)存的 70%寂曹。

• network.breaker.inflight requests.limit 限制當(dāng)前通過(guò)HTTP等進(jìn)來(lái)的請(qǐng)求使用內(nèi)存不能超過(guò)Node內(nèi)存的指定值哎迄。這個(gè)內(nèi)存主要是限制請(qǐng)求內(nèi)容的長(zhǎng)度。 默認(rèn)100%隆圆。

• script.max_compilations_per_minute

• 限制script并發(fā)執(zhí)行數(shù)漱挚，默認(rèn)值為15。

詳情可查看官方文檔：https://www.elastic.co/guide/en/elasticsearch/reference/6.4/circuit-breaker.html#fielddata-circuit-breaker

來(lái)看圖說(shuō)話(huà)（圖片來(lái)源于網(wǎng)絡(luò)渺氧，ES的JVM heap按使用場(chǎng)景分為可GC部分和常駐部分旨涝。 可GC部分內(nèi)存會(huì)隨著GC操作而被回收； 常駐部分不會(huì)被GC侣背，通常使用LRU策略來(lái)進(jìn)行淘汰）

image.png

image.png

common space(可GC)

image.png

綜上所述：

segment memory 這是沒(méi)辦法通過(guò)參數(shù)配置釋放的白华，通常跟index息息相關(guān)，close index贩耐、force merge均會(huì)釋放部分空間.

綜上所述弧腥，需要保證 segment memory 和 可gc的空間 +固定空間比不超過(guò)100%。由于熔斷器是按整個(gè)heap大小來(lái)計(jì)算的潮太，所以如果segment memory 過(guò)大管搪，仍然可能會(huì)導(dǎo)致OOM。

下面為設(shè)置其配置：

其實(shí)正常情況下es集群默認(rèn)配置足夠使用消别，這里我們控制下fielddata 的內(nèi)存使用

indices.fielddata.cache.size: 20%

restart

su - elk -c "/data/secoo_program/elasticsearch-6.4.0/bin/elasticsearch -d"

優(yōu)化內(nèi)存后的使用情況

image.png

image.png

如圖可看出抛蚤，內(nèi)存使用回收趨于平穩(wěn)，再看下系統(tǒng)整體監(jiān)控對(duì)比圖

image.png

image.png

可以看出 優(yōu)化前后效果明顯寻狂，優(yōu)化前系統(tǒng)基本處于FULL GC 的 STW 階段岁经，導(dǎo)致整個(gè)系統(tǒng)隨著數(shù)據(jù)逐漸增加而服務(wù)能力下降，優(yōu)化后系統(tǒng)穩(wěn)定運(yùn)行提供快速檢索能力蛇券。

三缀壤、性能優(yōu)化-索引篇

優(yōu)化了內(nèi)存使用后樊拓，系統(tǒng)的穩(wěn)定性得到了保障。因?yàn)槲覀兊膃s主要用于日志和skywalking 的數(shù)據(jù)存儲(chǔ)檢索塘慕，其使用方式寫(xiě)入遠(yuǎn)遠(yuǎn)大于檢索筋夏，所以對(duì)于其寫(xiě)入能力也有著一定的要求。

當(dāng)前目前對(duì)于skywalking 的寫(xiě)入如下

image.png

可以發(fā)現(xiàn)其寫(xiě)入能力非常低

在優(yōu)化前必然要了解其核心概念图呢，優(yōu)化都是基于理論基礎(chǔ)而來(lái)的条篷，網(wǎng)上有很多文章這里不詳細(xì)說(shuō)了，下面看一張圖理解下：

image.png

上圖展示了一個(gè)doc index/write請(qǐng)求過(guò)來(lái)蛤织，es為其建立倒排的過(guò)程赴叹，而index opt.的優(yōu)化點(diǎn)就主要集中在該posting list building過(guò)程，

1. doc write/index request comes
2. 根據(jù)自定義的routingId字段或者docId選擇routing shard
3. 為了提高容錯(cuò)指蚜，doc雙寫(xiě)
   • 寫(xiě)入es實(shí)例的memory buffer（此時(shí)doc未能被search）
   • 寫(xiě)入transLog的內(nèi)存
4. es實(shí)例在每個(gè)refresh interval里將heap里面的docs刷到lucene利用著的系統(tǒng)緩存里（此時(shí)doc能夠被search）
5. transLog根據(jù)配置的持久化到disk的策略乞巧，同步docs到磁盤(pán)（順序?qū)懕P(pán)）
6. transLog的clean up

先看一下優(yōu)化參數(shù)模版

PUT _template/skywalking
{
  "index_patterns": "skywalking*",
  "settings": {
    "index.indexing.slowlog.threshold.index.debug" : "2s",
    "index.indexing.slowlog.threshold.index.info" : "5s",
    "index.indexing.slowlog.threshold.index.trace" : "500ms",
    "index.indexing.slowlog.threshold.index.warn" : "10s",
    "index.optimize_auto_generated_id" : "true",
    "index.refresh_interval" : "30s",
    "index.search.slowlog.threshold.fetch.debug" : "500ms",
    "index.search.slowlog.threshold.fetch.info" : "800ms",
    "index.search.slowlog.threshold.fetch.trace" : "200ms",
    "index.search.slowlog.threshold.fetch.warn" : "1s",
    "index.search.slowlog.threshold.query.debug" : "2s",
    "index.search.slowlog.threshold.query.info" : "5s",
    "index.search.slowlog.threshold.query.trace" : "500ms",
    "index.search.slowlog.threshold.query.warn" : "10s",
    "index.translog.durability" : "async",
    "index.translog.flush_threshold_size" : "1gb",
    "index.translog.sync_interval" : "60s"
  }
}

對(duì)于網(wǎng)上很多資料有很多優(yōu)化參數(shù)，這里我們并不需要調(diào)整每一個(gè)摊鸡，通過(guò)理論可以看出绽媒，對(duì)于寫(xiě)入影響點(diǎn)有以下幾個(gè)：

memory Buffer -> FilesystemCache 影響參數(shù) refresh_interval: 1s，（將新生成的segment 刷入文件系統(tǒng)緩存中免猾，才可以被搜索到）

transLog-> Disk 每次 index是辕、bulk、delete掸刊、update 完成的時(shí)候免糕，一定觸發(fā)刷新 translog 到磁盤(pán)上，才給請(qǐng)求返回 200 OK

transLog-> empty transLog 這個(gè)階段主要影響內(nèi)存的回收忧侧，可以根據(jù) 大小 條數(shù) 時(shí)間自由設(shè)定石窑，默認(rèn)30m | 200M flush

auto doc id 如果手動(dòng)為es doc設(shè)置一個(gè)id，那么es在每個(gè)write req都要去確認(rèn)那個(gè)id是否存在

再經(jīng)過(guò)如上簡(jiǎn)單的參數(shù)優(yōu)化后蚓炬，整體索引情況如下

image.png

但3k 的index 速度也是遠(yuǎn)遠(yuǎn)達(dá)不到我們的要求的松逊，這里將使用esrally 對(duì)單分區(qū)進(jìn)行下寫(xiě)入壓力測(cè)試。

四肯夏、性能優(yōu)化-搜索篇（待完成）