一颜说、背景介紹

近一年內對公司的 ELK 日志系統(tǒng)做過性能優(yōu)化脑沿，也對 SkyWalking 使用的 ES 存儲進行過性能優(yōu)化庄拇，在此做一些總結溶弟。本篇主要是講 ES 在 ELK 架構中作為日志存儲時的性能優(yōu)化方案辜御。

ELK 架構作為日志存儲方案

ELK日志架構.png

二、現(xiàn)狀分析

1. 版本及硬件配置

• JDK：JDK1.8_171-b11 (64位)
• ES集群：由3臺16核32G的虛擬機部署 ES 集群碳抄，每個節(jié)點分配20G堆內存
• ELK版本：6.3.0
• 垃圾回收器：ES 默認指定的老年代（CMS）+ 新生代（ParNew）
• 操作系統(tǒng)：CentOS Linux release 7.4.1708(Core)

2. 性能問題

隨著接入ELK的應用越來越多，每日新增索引約 230 個璧尸，新增 document 約 3000萬到 5000萬。

每日上午和下午是日志上傳高峰期蛀序，在 Kibana 上查看日志哼拔，發(fā)現(xiàn)問題：
(1) 日志會有 5-40 分鐘的延遲
(2) 有很多日志丟失，無法查到

3. 問題分析

3.1 日志延遲

首先了解清楚：數據什么時候可以被查到檬姥？

數據先是存放在 ES 的內存 buffer，然后執(zhí)行 refresh 操作寫入到操作系統(tǒng)的內存緩存 os cache秉犹，此后數據就可以被搜索到崇堵。

所以狰贯，日志延遲可能是我們的數據積壓在 buffer 中沒有進入 os cache 涵紊。

3.2日志丟失

查看日志發(fā)現(xiàn)很多 write 拒絕執(zhí)行的情況

write 線程池拒絕任務的日志.png

從日志中可以看出 ES 的 write 線程池已經滿負荷，執(zhí)行任務的線程已經達到最大16個線程塘幅，而200容量的隊列也已經放不下新的task踏揣。

查看線程池的情況也可以看出 write 線程池有很多寫入的任務

GET /_cat/thread_pool?v&h=host,name,type,size,active,largest,rejected,completed,queue,queue_size

write 線程池拒絕任務的情況.png

所以我們需要優(yōu)化 ES 的 write 的性能又谋。

4.解決思路

4.1 分析場景

ES 的優(yōu)化分為很多方面，我們要根據使用場景考慮對 ES 的要求任斋。

根據個人實踐經驗废酷，列舉三種不同場景下的特點：

• SkyWalking：一般配套使用ES作為數據存儲澈蟆，存儲鏈路追蹤數據、指標數據等信息。
• ELK：一般用來存儲系統(tǒng)日志带膀，并進行分析，搜索嗽元，定位應用的問題剂癌。
• 全文搜索的業(yè)務：業(yè)務中常用 ES 作為全文搜索引擎，例如在外賣應用中监嗜，ES 用來存儲商家桐猬、美食的業(yè)務數據溃肪，用戶在客戶端可以根據關鍵字、地理位置等查詢條件搜索商家厨钻、美食信息莉撇。

這三類場景的特點如下：

關于實時性

• SkyWalking 在實際使用中，一般使用頻率不太高涂佃，往往是發(fā)現(xiàn)應用的問題后辜荠，再去 SkyWalking 查歷史鏈路追蹤數據或指標數據造烁，所以可以接受幾分鐘的延遲。
• ELK 不管是開發(fā)、測試等階段，時常用來定位應用的問題，如果不能快速查詢出數據我碟，延遲太久怎囚，會耽誤很多時間，大大降低工作效率贩虾；如果是查日志定位生產問題缎罢，那更是刻不容緩策精。
• 全文搜索的業(yè)務中一般可以接受在1分鐘內查看到最新數據，比如新商品上架一分鐘后才看到询刹，但盡量實時凹联，在幾秒內可以可看到住闯。

4.2 優(yōu)化的方向

可以從三方面進行優(yōu)化：JVM性能調優(yōu)、ES性能調優(yōu)春寿、控制數據來源

三绑改、ES性能優(yōu)化

可以從三方面進行優(yōu)化：JVM 性能調優(yōu)、ES 性能調優(yōu)、控制數據來源

1. JVM調優(yōu)

第一步是 JVM 調優(yōu)耳璧。
因為 ES 是依賴于 JVM 運行旨枯，沒有合理的設置 JVM 參數，將浪費資源昆汹，甚至導致 ES 很容易 OOM 而崩潰满粗。

1.1 監(jiān)控 JVM 運行情況

(1) 查看 GC 日志

GC日志中很多Young GC.png

(2) 使用 jstat 看下每秒的 GC 情況

jstat發(fā)現(xiàn)Young GC頻繁.png

• S0：幸存1區(qū)當前使用比例
• S1：幸存2區(qū)當前使用比例
• E：伊甸園區(qū)使用比例
• O：老年代使用比例
• M：元數據區(qū)使用比例
• CCS：壓縮使用比例
• YGC：年輕代垃圾回收次數
• FGC：老年代垃圾回收次數
• FGCT：老年代垃圾回收消耗時間
• GCT：垃圾回收消耗總時間
  問題：從 jstat gc 中也可以看出，每秒的 eden 增長速度非嘲樱快，很快就滿了勃蜘。

1.2 定位 Young GC 頻繁的原因

1.2.1 檢查是否新生代的空間是否太小

用下面幾種方式都可查看新、老年代內存大小
(1) 使用 jstat -gc pid 查看 Eden 區(qū)阳惹、老年代空間大小
(2) 使用 jmap -heap pid 查看 Eden 區(qū)穆端、老年代空間大小
(3) 查看 GC 日志中的 GC 明細

GC明細.png

上面的幾種方式都查詢出攒巍，新生代總內存約1081M嗽仪，即1G左右；老年代總內存為19864000K柒莉，約19G闻坚。新仅偎、老比例約1:19，出乎意料。

1.2.1 新老年代空間比例為什么不是 JDK 默認的1:2【重點弦牡！】

這真是一個容易踩坑的地方椭豫。
如果沒有顯示設置新生代大小搬素，JVM 在使用 CMS 收集器時會自動調參，新生代的大小在沒有設置的情況下是通過計算得出的桑嘶，其大小可能與 NewRatio 的默認配置沒什么關系而與 ParallelGCThreads 的配置有一定的關系。

參考：CMS GC 默認新生代是多大？

所以：新生代大小有不確定性寸五，最好配置 JVM 參數 -XX:NewSize劲适、-XX:MaxNewSize 或者 -xmn ，免得遇到一些奇怪的 GC败晴，讓人措手不及纯路。

1.3 上面現(xiàn)象造成的影響

新生代過小搓逾，老年代過大的影響

• 新生代過小:
  (1) 會導致新生代 Eden 區(qū)很快用完矛市，而觸發(fā) Young GC墩衙，Young GC 的過程中會 STW(Stop The World)奔滑，也就是所有工作線程停止入蛆，只有 GC 的線程在進行垃圾回收食店，這會導致 ES 短時間停頓。頻繁的 Young GC旱眯，積少成多蓬蝶，對系統(tǒng)性能影響較大梨撞。
  (2) 大部分對象很快進入老年代旦签，老年代很容易用完而觸發(fā) Full GC喧笔。
• 老年代過大：會導致 Full GC 的執(zhí)行時間過長帽驯，F(xiàn)ull GC 雖然有并行處理的步驟，但是還是比 Young GC 的 STW 時間更久溃斋，而 GC 導致的停頓時間在幾十毫秒到幾秒內界拦，很影響 ES 的性能，同時也會導致請求 ES 服務端的客戶端在一定時間內沒有響應而發(fā)生 timeout 異常梗劫，導致請求失敗享甸。

1.4 JVM優(yōu)化

1.4.1 配置堆內存空間大小

32G 的內存，分配 20G 給堆內存是不妥當的梳侨，所以調整為總內存的50%蛉威，即16G。
修改 elasticsearch 的 jvm.options 文件

-Xms16g
-Xmx16g

設置要求:

• Xms 與 Xmx 大小相同走哺。

  在 jvm 的參數中 -Xms 和 -Xmx 設置的不一致蚯嫌，在初始化時只會初始 -Xms 大小的空間存儲信息，每當空間不夠用時再向操作系統(tǒng)申請丙躏，這樣的話必然要進行一次 GC择示，GC會帶來 STW。而剩余空間很多時晒旅，會觸發(fā)縮容栅盲。再次不夠用時再擴容，如此反復废恋，這些過程會影響系統(tǒng)性能谈秫。同理在 MetaSpace 區(qū)也有類似的問題扒寄。

• jvm 建議不要超過 32G，否則 jvm 會禁用內存對象指針壓縮技術拟烫，造成內存浪費

• Xmx 和 Xms 不要超過物理 RAM 的50%该编。 參考：官方堆內存設置的建議

  Xmx 和 Xms 不要超過物理內存的50%。Elasticsearch 需要內存用于JVM堆以外的其他用途硕淑，為此留出空間非常重要课竣。例如，Elasticsearch 使用堆外緩沖區(qū)進行有效的網絡通信喜颁，依靠操作系統(tǒng)的文件系統(tǒng)緩存來高效地訪問文件稠氮，而 JVM 本身也需要一些內存。

1.4.2 配置堆內存新生代空間大小

因為指定新生代空間大小半开，導致 JVM 自動調參只分配了 1G 內存給新生代。

修改 elasticsearch 的 jvm.options 文件赃份，加上

-XX:NewSize=8G
-XX:MaxNewSize=8G

老年代則自動分配 16G-8G=8G 內存寂拆，新生代老年代的比例為 1:1。修改后每次 Young GC 頻率更低抓韩，且每次 GC 后只有少數數據會進入老年代纠永。

2.3 使用G1垃圾回收器(未實踐)

G1垃圾回收器讓系統(tǒng)使用者來設定垃圾回收堆系統(tǒng)的影響，然后把內存拆分為大量的小 Region谒拴，追蹤每個 Region 中可以回收的對象大小和回收完成的預計花費的時間尝江， 最后在垃圾回收的時候，盡量把垃圾回收對系統(tǒng)造成的影響控制在我們指定的時間范圍內英上，同時在有限的時間內盡量回收更多的垃圾對象炭序。
G1垃圾回收器一般在大數量、大內存的情況下有更好的性能苍日。

ES默認使用的垃圾回收器是：老年代（CMS）+ 新生代（ParNew）惭聂。如果是JDK1.9，ES 默認使用G1垃圾回收器相恃。

因為使用的是 JDK1.8辜纲，所以并未切換垃圾回收器。后續(xù)如果再有性能問題再切換G1垃圾回收器拦耐，測試是否有更好的性能耕腾。

1.5 優(yōu)化的效果

1.5.1 新生代使用內存的增長率更低

優(yōu)化前

優(yōu)化前.png

每秒打印一次 GC 數據∩迸矗可以看出扫俺，年輕代增長速度很快，幾秒鐘年輕代就滿了火脉，導致 Young GC 觸發(fā)很頻繁牵舵，幾秒鐘就會觸發(fā)一次柒啤。而每次 Young GC 很大可能有存活對象進入老年代，而且畸颅，存活對象多的時候(看上圖中第一個紅框中的old gc數據)担巩，有(51.44-51.08)/100 * 19000M = 約68M。每次進入老年代的對象較多没炒，加上頻繁的 Young GC涛癌，會導致新老年代的分代模式失去了作用，相當于老年代取代了新生代來存放近期內生成的對象送火。當老年代滿了拳话，觸發(fā) Full GC，存活的對象也會很多种吸，因為這些對象很可能還是近期加入的弃衍，還存活著，所以一次 Full GC 回收對象不多坚俗。而這會惡性循環(huán)镜盯，老年代很快又滿了，又 Full GC猖败，又殘留一大部分存活的速缆，又很容易滿了，所以導致一直頻繁 Full GC恩闻。

優(yōu)化后

優(yōu)化后.png

每秒打印一次 GC 數據艺糜。可以看出幢尚，新生代增長速度慢了許多破停，至少要60秒才會滿，如上圖紅框中數據侠草，進入老年代的對象約(15.68-15.60)/100 * 10000 = 8M辱挥，非常的少。所以要很久才會觸發(fā)一次 Full GC 边涕。而且等到 Full GC 時晤碘，老年代里很多對象都是存活了很久的，一般都是不會被引用功蜓，所以很大一部分會被回收掉园爷，留一個比較干凈的老年代空間，可以繼續(xù)放很多對象式撼。

1.5.2 新生代和老年代 GC 頻率更低

ES 啟動后童社，運行14個小時

優(yōu)化前

優(yōu)化前.png

Young GC 每次的時間是不長的，從上面監(jiān)控數據中可以看出每次GC時長 1467.995/27276 約等于 0.05秒著隆。那一秒鐘有多少時間實在處理Young GC ? 計算公式：1467秒/(60秒×60分14小時）= 約0.028秒扰楼，也就是100秒中就有2.8秒在Young GC呀癣，也就是有2.8S的停頓，這對性能還是有很大消耗的弦赖。同時也可以算出多久一次Young GC项栏， 方程是： 60秒×60分*14小時/ 27276次 = 1次/X秒，計算得出X = 0.54蹬竖，也就是0.54秒就會有一次Young GC沼沈，可見 Young GC 頻率非常頻繁。

優(yōu)化后

優(yōu)化后效果.png

Young GC 次數只有修改前的十分之一币厕，Young GC 時間也是約八分之一列另。Full GC 的次數也是只有原來的八分之一，GC 時間大約是四分之一旦装。

GC 對系統(tǒng)的影響大大降低页衙，性能已經得到很大的提升。

2.ES調優(yōu)

上面已經分析過ES作為日志存儲時的特性是：高并發(fā)寫同辣、讀少拷姿、接受30秒內的延時、可容忍部分日志數據丟失旱函。
下面我們針對這些特性對ES進行調優(yōu)。

2.1 優(yōu)化 ES 索引設置

2.2.1 ES 寫數據底層原理

本人整理了一下數據寫入的底層原理

ES寫入數據的原理.png

refresh
ES 接收數據請求時先存入 ES 的內存中描滔，默認每隔一秒會從內存 buffer 中將數據寫入操作系統(tǒng)緩存 os cache棒妨，這個過程叫做 refresh；

到了 os cache 數據就能被搜索到（所以我們才說 ES 是近實時的含长，因為1s 的延遲后執(zhí)行 refresh 便可讓數據被搜索到）

fsync
translog 會每隔5秒或者在一個變更請求完成之后執(zhí)行一次 fsync 操作券腔，將 translog 從緩存刷入磁盤，這個操作比較耗時拘泞，如果對數據一致性要求不是跟高時建議將索引改為異步纷纫，如果節(jié)點宕機時會有5秒數據丟失;

flush
ES 默認每隔30分鐘會將 os cache 中的數據刷入磁盤同時清空 translog 日志文件，這個過程叫做 flush陪腌。

merge

ES 的一個 index 由多個 shard 組成辱魁，而一個 shard 其實就是一個 Lucene 的 index ，它又由多個 segment 組成诗鸭，且 Lucene 會不斷地把一些小的 segment 合并成一個大的 segment 染簇，這個過程被稱為段merge。執(zhí)行索引操作時强岸，ES會先生成小的segment锻弓，ES 有離線的邏輯對小的 segment 進行合并，優(yōu)化查詢性能蝌箍。但是合并過程中會消耗較多磁盤 IO青灼，會影響查詢性能暴心。

2.2.2 優(yōu)化方向

2.2.2.1 優(yōu)化 fsync

為了保證不丟失數據，就要保護 translog 文件的安全:

Elasticsearch 2.0 之后, 每次寫請求(如 index 杂拨、delete专普、update、bulk 等)完成時, 都會觸發(fā)fsync將 translog 中的 segment 刷到磁盤, 然后才會返回200 OK的響應;

或者: 默認每隔5s就將 translog 中的數據通過fsync強制刷新到磁盤.

該方式提高數據安全性的同時扳躬， 降低了一點性能.

==> 頻繁地執(zhí)行fsync操作, 可能會產生阻塞導致部分操作耗時較久. 如果允許部分數據丟失, 可設置異步刷新 translog 來提高效率脆诉，還有降低 flush 的閥值，優(yōu)化如下：

"index.translog.durability": "async",
"index.translog.flush_threshold_size":"1024mb",
"index.translog.sync_interval": "120s"

2.2.2.2 優(yōu)化 refresh

寫入 Lucene 的數據贷币，并不是實時可搜索的击胜，ES 必須通過 refresh 的過程把內存中的數據轉換成 Lucene 的完整 segment 后，才可以被搜索役纹。

默認1秒后偶摔，寫入的數據可以很快被查詢到，但勢必會產生大量的 segment促脉，檢索性能會受到影響辰斋。所以，加大時長可以降低系統(tǒng)開銷瘸味。對于日志搜索來說宫仗，實時性要求不是那么高，設置為5秒或者10s旁仿；對于SkyWalking藕夫，實時性要求更低一些，我們可以設置為30s枯冈。

設置如下：

"index.refresh_interval":"5s"

2.2.2.3 優(yōu)化 merge

index.merge.scheduler.max_thread_count 控制并發(fā)的 merge 線程數毅贮，如果存儲是并發(fā)性能較好的 SSD，可以用系統(tǒng)默認的 max(1, min(4, availableProcessors / 2))尘奏，當節(jié)點配置的 cpu 核數較高時滩褥，merge 占用的資源可能會偏高，影響集群的性能炫加，普通磁盤的話設為1瑰煎，發(fā)生磁盤 IO 堵塞。設置max_thread_count 后琢感，會有 max_thread_count + 2 個線程同時進行磁盤操作丢间，也就是設置為 1 允許3個線程。

設置如下：

"index.merge.scheduler.max_thread_count":"1"

2.2.2 優(yōu)化設置

2.2.2.1 對現(xiàn)有索引做索引設置

# 需要先 close 索引,然后再執(zhí)行,最后成功之后再打開
# 關閉索引
curl -XPOST 'http://localhost:9200/_all/_close'

# 修改索引設置
curl -XPUT -H "Content-Type:application/json" 'http://localhost:9200/_all/_settings?preserve_existing=true' -d '{"index.merge.scheduler.max_thread_count" : "1","index.refresh_interval" : "10s","index.translog.durability" : "async","index.translog.flush_threshold_size":"1024mb","index.translog.sync_interval" : "120s"}'

# 打開索引
curl -XPOST 'http://localhost:9200/_all/_open'

該方式可對已經生成的索引做修改驹针，但是對于后續(xù)新建的索引不生效烘挫，所以我們可以制作 ES 模板，新建的索引按模板創(chuàng)建索引。

2.2.2.2 制作索引模板

# 制作模板 大部分索引都是業(yè)務應用的日志相關的索引饮六，且索引名稱是 202* 這種帶著日期的格式
PUT _template/business_log
{
  "index_patterns": ["*202*.*.*"],
  "settings": {
  "index.merge.scheduler.max_thread_count" : "1","index.refresh_interval" : "5s","index.translog.durability" : "async","index.translog.flush_threshold_size":"1024mb","index.translog.sync_interval" : "120s"}
}

# 查詢模板是否創(chuàng)建成功
GET _template/business_log

因為我們的業(yè)務日志是按天維度創(chuàng)建索引其垄，索引名稱示例：user-service-prod-2020.12.12，所以用通配符202..*匹配對應要創(chuàng)建的業(yè)務日志索引卤橄。

2.2 優(yōu)化線程池配置

前文已經提到過绿满，write 線程池滿負荷，導致拒絕任務窟扑，而有的數據無法寫入喇颁。

而經過上面的優(yōu)化后，拒絕的情況少了很多嚎货，但是還是有拒絕任務的情況橘霎。

所以我們還需要優(yōu)化write線程池。

從 prometheus 監(jiān)控中可以看到線程池的情況：

為了更直觀看到ES線程池的運行情況殖属，我們安裝了 elasticsearch_exporter 收集 ES 的指標數據到 prometheus姐叁，再通過 grafana 進行查看。

經過上面的各種優(yōu)化洗显，拒絕的數據量少了很多外潜，但是還是存在拒絕的情況，如下圖：

image.png

write 線程池如何設置：

參考：ElasticSearch線程池

write

For single-document index/delete/update and bulk requests. Thread pool type is fixed with a size of # of available processors, queue_size of 200. The maximum size for this pool is 1 + # of available processors.

write 線程池采用 fixed 類型的線程池挠唆，也就是核心線程數與最大線程數值相同处窥。線程數默認等于 cpu 核數，可設置的最大值只能是 cpu 核數加1玄组，也就是16核CPU碧库，能設置的線程數最大值為17。

優(yōu)化的方案：

• 線程數改為17巧勤，也就是 cpu 總核數加1
• 隊列容量加大。隊列在此時的作用是消峰弄匕。不過隊列容量加大本身不會提升處理速度颅悉，只是起到緩沖作用。此外迁匠，隊列容量也不能太大剩瓶，否則積壓很多任務時會占用過多堆內存。

config/elasticsearch.yml文件增加配置

# 線程數設置
thread_pool:
  write:
    # 線程數默認等于cpu核數城丧，即16  
    size: 17
    # 因為任務多時存在任務拒絕的情況延曙，所以加大隊列大小，可以在間歇性任務量陡增的情況下亡哄，緩存任務在隊列枝缔，等高峰過去逐步消費完。
    queue_size: 10000

優(yōu)化后效果

線程池拒絕的情況.png

2.３ 鎖定內存，不讓 JVM 使用 Swap

Swap 交換分區(qū):

Swap 分區(qū)通常被稱為交換分區(qū)趴荸，這是一塊特殊的硬盤空間儒溉，即當物理內存不夠用的時候，操作系統(tǒng)會從物理內存中取出一部分暫時不用的數據发钝，放在交換分區(qū)中顿涣，從而為當前運行的程序騰出足夠的內存空間。也就是當物理內存不夠用時酝豪，用磁盤來頂替物理內存涛碑。
優(yōu)點是：通過操作系統(tǒng)的調度，應用程序實際可以使用的內存空間將遠遠超過系統(tǒng)的物理內存寓调。由于硬盤空間的價格遠比 RAM 要低锌唾，因此這種方式無疑是經濟實惠的。
缺點是：頻繁地讀寫硬盤夺英，會顯著降低操作系統(tǒng)的運行速率晌涕，這也是使用 swap 交換分區(qū)最大的限制。

參考：ElasticSearch官方解釋為什么要禁用交換內存

Swap 交換分區(qū)對性能和節(jié)點穩(wěn)定性非常不利痛悯，一定要禁用余黎。它會導致垃圾回收持續(xù)幾分鐘而不是幾毫秒，并會導致節(jié)點響應緩慢载萌，甚至與集群斷開連接惧财。

有三種方式可以實現(xiàn) ES 不使用Swap分區(qū)

2.3.1 Linux 系統(tǒng)中的關閉 Swap (臨時有效)

執(zhí)行命令

sudo swapoff -a

可以臨時禁用 Swap 內存，但是操作系統(tǒng)重啟后失效

2.3.2 Linux 系統(tǒng)中的盡可能減少 Swap 的使用(永久有效)

執(zhí)行下列命令

echo "vm.swappiness = 1">> /etc/sysctl.conf

正常情況下不會使用 Swap扭仁，除非緊急情況下才會 Swap垮衷。

2.3.3 啟用 bootstrap.memory_lock

config/elasticsearch.yml 文件增加配置

#鎖定內存，不讓 JVM 寫入 Swap乖坠，避免降低 ES 的性能
bootstrap.memory_lock: true

2.4 減少分片數搀突、副本數

分片

索引的大小取決于分片與段的大小，分片過小熊泵，可能導致段過小仰迁，進而導致開銷增加；分片過大可能導致分片頻繁 Merge顽分，產生大量 IO 操作徐许，影響寫入性能。

因為我們每個索引的大小在15G以下卒蘸，而默認是5個分片雌隅，沒有必要這么多，所以調整為3個。

"index.number_of_shards": "3"

分片的設置我們也可以配置在索引模板澄步。

副本數

減少集群副本分片數冰蘑，過多副本會導致 ES 內部寫擴大。副本數默認為1村缸，如果某索引所在的1個節(jié)點宕機祠肥，擁有副本的另一臺機器擁有索引備份數據，可以讓索引數據正常使用梯皿。但是數據寫入副本會影響寫入性能仇箱。對于日志數據，有1個副本即可东羹。對于大數據量的索引剂桥，可以設置副本數為0，減少對性能的影響属提。

"index.number_of_replicas": "1"

分片的設置我們也可以配置在索引模板权逗。

3.控制數據來源

3.1 應用按規(guī)范打印日志

有的應用1天生成10G日志，而一般的應用只有幾百到1G冤议。一天生成10G日志一般是因為部分應用日志使用不當斟薇，很多大數量的日志可以不打，比如大數據量的列表查詢接口恕酸、報表數據堪滨、debug 級別日志等數據是不用上傳到日志服務器，這些即影響日志存儲的性能蕊温，更影響應用自身性能袱箱。

四、ES性能優(yōu)化后的效果

優(yōu)化后的兩周內ELK性能良好义矛，沒有使用上的問題：

• ES 數據不再丟失

• 數據延時在10秒之內发笔，一般在5秒可以查出

• 每個 ES 節(jié)點負載比較穩(wěn)定，CPU 和內存使用率都不會過高凉翻，如下圖

  ES節(jié)點運行情況.png

五筐咧、參考文檔

參考

記一次 ElasticSearch 優(yōu)化總結

ElasticSearch 的數據寫入流程及優(yōu)化

百億級實時計算系統(tǒng)性能優(yōu)化–—ElasticSearch篇