??

目錄

監(jiān)控 API

調(diào)優(yōu)

1、CPU使用率

ES中導(dǎo)致CPU 變高的因素

ES導(dǎo)致CPU 變高的解決方案

? ? ? ? ?2、內(nèi)存使用率

ES內(nèi)存使用率 過高的可能因素

ES內(nèi)存使用率 過高的處理方案

3、ES磁盤使用率

ES磁盤使用率過高的可能因素

4、ES 中GC頻次

ES 中GC頻次增加的可能因素

ES 中GC頻次降低GC頻次的方案

5、ES中fielddata內(nèi)存

ES中fielddata內(nèi)存使用量增加的可能因素

ES 中fielddata內(nèi)存使用量增高時的解決方案

?一個 Elasticsearch 集群至少包括一個節(jié)點(diǎn)和一個索引?；蛘咚赡苡幸话賯€數(shù)據(jù)節(jié)點(diǎn)、三個單獨(dú)的主節(jié)點(diǎn)，以及一小打客戶端節(jié)點(diǎn)——這些共同操作一千個索引（以及上萬個分片）。

不管集群擴(kuò)展到多大規(guī)模，你都會想要一個快速獲取集群狀態(tài)的途徑。Cluster Health?API 充當(dāng)?shù)木褪沁@個角色。你可以把它想象成是在一萬英尺的高度鳥瞰集群。它可以告訴你安心吧一切都好，或者警告你集群某個地方有問題。

監(jiān)控 API

讓我們執(zhí)行一下?cluster-health?API ：

GET _cluster/health

response: 返回集群概覽信息

{
   "cluster_name": "elasticsearch_zach",
   "status": "green",
   "timed_out": false,
   "number_of_nodes": 1,
   "number_of_data_nodes": 1,
   "active_primary_shards": 10,
   "active_shards": 10,
   "relocating_shards": 0,
   "initializing_shards": 0,
   "unassigned_shards": 0
}

響應(yīng)信息中最重要的一個指標(biāo)?status?字段。狀態(tài)可能是下列三個值之一：

green

所有的主分片和副本分片都已分配。你的集群是 100% 可用的。

yellow

所有的主分片已經(jīng)分片了，但至少還有一個副本是缺失的。不會有數(shù)據(jù)丟失，所以搜索結(jié)果依然是完整的。不過，你的高可用性在某種程度上被弱化。如果?更多的?分片消失，你就會丟數(shù)據(jù)了。把?yellow?想象成一個需要及時調(diào)查的警告。

red

至少一個主分片（以及它的全部副本）都在缺失中。這意味著你在缺少數(shù)據(jù)：搜索只能返回部分?jǐn)?shù)據(jù)，而分配到這個分片上的寫入請求會返回一個異常。

剩下來的指標(biāo)給你列出來集群的狀態(tài)概要：

• number_of_nodes?和?number_of_data_nodes?這個命名完全是自描述的。
• active_primary_shards?指出你集群中的主分片數(shù)量。這是涵蓋了所有索引的匯總值。
• active_shards?是涵蓋了所有索引的_所有_分片的匯總值，即包括副本分片。
• relocating_shards?顯示當(dāng)前正在從一個節(jié)點(diǎn)遷往其他節(jié)點(diǎn)的分片的數(shù)量。通常來說應(yīng)該是 0，不過在 Elasticsearch 發(fā)現(xiàn)集群不太均衡時，該值會上漲。比如說：添加了一個新節(jié)點(diǎn)，或者下線了一個節(jié)點(diǎn)。
• initializing_shards?是剛剛創(chuàng)建的分片的個數(shù)。比如，當(dāng)你剛創(chuàng)建第一個索引，分片都會短暫的處于?initializing?狀態(tài)。這通常會是一個臨時事件，分片不應(yīng)該長期停留在?initializing?狀態(tài)。你還可能在節(jié)點(diǎn)剛重啟的時候看到?initializing?分片：當(dāng)分片從磁盤上加載后，它們會從?initializing?狀態(tài)開始。
• unassigned_shards?是已經(jīng)在集群狀態(tài)中存在的分片，但是實(shí)際在集群里又找不著。通常未分配分片的來源是未分配的副本。比如，一個有 5 分片和 1 副本的索引，在單節(jié)點(diǎn)集群上，就會有 5 個未分配副本分片。如果你的集群是?red?狀態(tài)，也會長期保有未分配分片（因?yàn)槿鄙僦鞣制?/li>

如果發(fā)現(xiàn)status 變?yōu)閞ed ，我們就需要進(jìn)一步排查具體原因；定位具體那個分片的索引有問題；執(zhí)行以下API?

GET _cluster/health?level=indices

response 有關(guān)每個索引的細(xì)節(jié)（狀態(tài)、分片數(shù)、未分配分片數(shù)等等）；

{
   "cluster_name": "elasticsearch_zach",
   "status": "red",
   "timed_out": false,
   "number_of_nodes": 8,
   "number_of_data_nodes": 8,
   "active_primary_shards": 90,
   "active_shards": 180,
   "relocating_shards": 0,
   "initializing_shards": 0,
   "unassigned_shards": 20
   "indices": {
      "v_1": {
         "status": "green",
         "number_of_shards": 10,
         "number_of_replicas": 1,
         "active_primary_shards": 10,
         "active_shards": 20,
         "relocating_shards": 0,
         "initializing_shards": 0,
         "unassigned_shards": 0
      },
      "v_2": {
         "status": "red", 
         "number_of_shards": 10,
         "number_of_replicas": 1,
         "active_primary_shards": 0,
         "active_shards": 0,
         "relocating_shards": 0,
         "initializing_shards": 0,
         "unassigned_shards": 20 
      },
      "v_3": {
         "status": "green",
         "number_of_shards": 10,
         "number_of_replicas": 1,
         "active_primary_shards": 10,
         "active_shards": 20,
         "relocating_shards": 0,
         "initializing_shards": 0,
         "unassigned_shards": 0
      },
      ....
   }
}

可以看到?v_2?索引就是讓集群變?red?的那個索引;

? ? ?我們還可以看到這個索引曾經(jīng)有 10 個主分片和一個副本，而現(xiàn)在這 20 個分片全不見了?？梢酝茰y，這 20 個索引就是位于從我們集群里不見了的那兩個節(jié)點(diǎn)上。

GET _cluster/health?level=shards

?shards?選項(xiàng)會提供一個詳細(xì)得多的輸出，列出每個索引里每個分片的狀態(tài)和位置。這個輸出有時候很有用，但是由于太過詳細(xì)會比較難用。

以上是ES 的原生API,也可以搭建kbana 等客戶端界面更好的觀察集群狀態(tài)；

調(diào)優(yōu)

? ? ? 調(diào)優(yōu)是一個優(yōu)化程序運(yùn)行性能的過程，需要結(jié)合經(jīng)驗(yàn)，分析系統(tǒng)數(shù)據(jù)來找到性能瓶頸；然后有針對性的去優(yōu)化提高性能；那么對于es 這種java 語言編程的程序，我們可以從以下幾個方面去分析：

1、CPU使用率

CPU使用率是指在一段時間內(nèi)CPU執(zhí)行程序的百分比，它是衡量系統(tǒng)資源利用率的一種指標(biāo)。

詳細(xì)說明：
在Elasticsearch中，高的CPU使用率通常意味著節(jié)點(diǎn)正在執(zhí)行大量的計(jì)算任務(wù)，這可能是因?yàn)樗饕退阉鞑僮鞯呢?fù)載較大，也可能是因?yàn)楣?jié)點(diǎn)正在進(jìn)行數(shù)據(jù)復(fù)制和分片重新平衡等任務(wù)。因此，高的CPU使用率通常是Elasticsearch性能瓶頸的一個指標(biāo)。

ES中導(dǎo)致CPU 變高的因素

查詢負(fù)載增加：當(dāng) Elasticsearch 集群承受的查詢負(fù)載增加時，會導(dǎo)致 CPU 使用率變高。這通常發(fā)生在索引大量新數(shù)據(jù)或者搜索流量增加的情況下。

索引負(fù)載增加：當(dāng) Elasticsearch 集群承受的索引負(fù)載增加時，會導(dǎo)致 CPU 使用率變高。這通常發(fā)生在索引大量新數(shù)據(jù)的情況下。

GC：當(dāng) Elasticsearch 的 Java 進(jìn)程發(fā)生垃圾回收（GC）時，會導(dǎo)致 CPU 使用率變高。GC 是清理 Java 堆內(nèi)存中不再使用的對象，它是 Java 程序中自帶的機(jī)制，當(dāng) Java 堆內(nèi)存中的對象數(shù)量增加時，GC 的頻率和時間也會相應(yīng)增加。

機(jī)器性能不足：當(dāng) Elasticsearch 部署的機(jī)器性能不足時，會導(dǎo)致 CPU 使用率變高。例如，CPU 處理器的速度較慢，內(nèi)存不足，磁盤 I/O 較慢等。

插件/腳本等造成的性能問題：當(dāng) Elasticsearch 使用的插件或腳本存在性能問題時，會導(dǎo)致 CPU 使用率變高。在某些情況下，某些插件和腳本可能會影響 Elasticsearch 的性能，例如使用復(fù)雜的腳本或者調(diào)用較慢的第三方庫。

總之，當(dāng) Elasticsearch 集群處理數(shù)據(jù)量增加、索引負(fù)載增加、查詢負(fù)載增加、GC 或者機(jī)器性能不足等情況時，會導(dǎo)致 CPU 使用率變高。為了避免這種情況的發(fā)生，可以采取一些優(yōu)化策略，如添加更多的節(jié)點(diǎn)、升級硬件等。

ES導(dǎo)致CPU 變高的解決方案

調(diào)整集群配置。可以通過調(diào)整Elasticsearch集群的配置來減少CPU的使用率。例如，可以調(diào)整查詢的并發(fā)數(shù)、增加分片的數(shù)量、減少索引的副本數(shù)等，來減輕CPU的負(fù)擔(dān)。

優(yōu)化查詢語句。復(fù)雜的查詢語句可能會導(dǎo)致CPU的使用率飆升。因此，可以考慮優(yōu)化查詢語句，使用更簡單、更高效的查詢語句來減少CPU的使用率。

關(guān)閉不必要的插件。Elasticsearch的插件可以擴(kuò)展其功能，但某些插件可能會占用大量的CPU資源。因此，可以考慮關(guān)閉某些不必要的插件來減少CPU的使用率。

增加硬件資源。如果Elasticsearch集群的CPU使用率經(jīng)常超過限制，可能需要考慮增加硬件資源，例如增加CPU核心數(shù)量或升級CPU型號，以提高集群的性能。

增加集群規(guī)模。如果Elasticsearch集群的CPU使用率經(jīng)常超過限制，還可以考慮增加集群規(guī)模，將負(fù)載分?jǐn)偟蕉嗯_機(jī)器上，以提高集群的性能。

調(diào)整集群中節(jié)點(diǎn)的負(fù)載均衡策略。Elasticsearch的負(fù)載均衡策略可能會導(dǎo)致某些節(jié)點(diǎn)的CPU使用率過高。因此，可以考慮調(diào)整負(fù)載均衡策略，將負(fù)載更均衡地分配到各個節(jié)點(diǎn)上。

Elasticsearch集群的CPU使用率升高時，可以考慮調(diào)整哪些參數(shù)：
indices.store.throttle.max_bytes_per_sec: 索引寫入速度控制參數(shù)，用于限制每秒寫入的數(shù)據(jù)量。如果寫入速度太快，可能會導(dǎo)致CPU使用率過高?？梢越档驮搮?shù)的值來減緩寫入速度。該參數(shù)的最優(yōu)值取決于硬件配置和寫入負(fù)載，一般建議將其設(shè)置為每秒寫入速率的80%到90%。例如，如果每秒寫入速率為50MB/s，則該參數(shù)的最優(yōu)值可能在40MB/s到45MB/s之間。

indices.memory.index_buffer_size: 索引緩沖區(qū)大小。如果該值太小，會導(dǎo)致頻繁的IO操作，從而增加CPU負(fù)載。可以適當(dāng)增大該值來減少IO操作。該參數(shù)的最優(yōu)值取決于可用內(nèi)存、索引大小和查詢負(fù)載等因素，一般建議將其設(shè)置為可用內(nèi)存的20%到30%。例如，如果集群有100GB的可用內(nèi)存，該參數(shù)的最優(yōu)值可能在20GB到30GB之間。

indices.fielddata.cache.size: 字段數(shù)據(jù)緩存大小。如果字段數(shù)據(jù)緩存過小，可能會導(dǎo)致頻繁的磁盤讀取，從而增加CPU負(fù)載?？梢赃m當(dāng)增大該值來減少磁盤讀取操作。該參數(shù)的最優(yōu)值取決于字段數(shù)據(jù)大小和查詢負(fù)載等因素，一般建議將其設(shè)置為可用內(nèi)存的20%到30%。例如，如果集群有100GB的可用內(nèi)存，該參數(shù)的最優(yōu)值可能在20GB到30GB之間。

indices.queries.cache.size: 查詢緩存大小。如果查詢緩存過小，可能會導(dǎo)致頻繁的查詢操作，從而增加CPU負(fù)載?？梢赃m當(dāng)增大該值來減少查詢操作。該參數(shù)的最優(yōu)值取決于查詢負(fù)載，一般建議將其設(shè)置為查詢緩存占用可用內(nèi)存的20%到30%。例如，如果集群有100GB的可用內(nèi)存，該參數(shù)的最優(yōu)值可能在20GB到30GB之間。

indices.recovery.max_bytes_per_sec: 索引恢復(fù)速度控制參數(shù)，用于限制每秒恢復(fù)的數(shù)據(jù)量。如果恢復(fù)速度太快，可能會導(dǎo)致CPU使用率過高?？梢越档驮搮?shù)的值來減緩恢復(fù)速度。該參數(shù)的最優(yōu)值取決于恢復(fù)速度和集群負(fù)載，一般建議將其設(shè)置為每秒恢復(fù)速率的80%到90%。例如，如果每秒恢復(fù)速率為50MB/s，則該參數(shù)的最優(yōu)值可能在40MB/s到45MB/s之間。

indices.search.slowlog.threshold.query.warn: 查詢慢日志告警閾值。如果查詢操作太慢，可能會導(dǎo)致CPU使用率過高?？梢越档驮搮?shù)的值來快速發(fā)現(xiàn)查詢慢的問題。該參數(shù)的最優(yōu)值取決于查詢負(fù)載和業(yè)務(wù)需求，一般建議將其設(shè)置為查詢執(zhí)行時間的90%到95%。例如，如果查詢執(zhí)行時間的中位數(shù)為1秒，則該參數(shù)的最優(yōu)值可能在900ms到950ms之間。

2、內(nèi)存使用率

當(dāng)前使用的內(nèi)存量占可用內(nèi)存總量的比例。

詳細(xì)說明：
Elasticsearch 會使用 JVM 來運(yùn)行，因此 JVM 的內(nèi)存分配對 Elasticsearch 的性能非常重要。默認(rèn)情況下，Elasticsearch 的 JVM 內(nèi)存分配為 1GB，但在生產(chǎn)環(huán)境中通常需要將其調(diào)整為更大的值。

Elasticsearch 將內(nèi)存分為兩部分：堆內(nèi)存和非堆內(nèi)存。堆內(nèi)存用于存儲文檔、字段和查詢緩存等數(shù)據(jù)，非堆內(nèi)存用于存儲索引緩存、文件系統(tǒng)緩存和其他內(nèi)部緩存等數(shù)據(jù)。

Elasticsearch 會自動管理緩存，以確保常用的數(shù)據(jù)在內(nèi)存中。當(dāng)內(nèi)存不足時，Elasticsearch 會將較少使用的數(shù)據(jù)從內(nèi)存中移除，并將其存儲到磁盤上。

對于單個節(jié)點(diǎn)的 Elasticsearch 集群，通常建議將 JVM 堆內(nèi)存設(shè)置為總內(nèi)存的一半，以留出一定的空間給操作系統(tǒng)和其他進(jìn)程使用。而對于大型集群，建議將 JVM 堆內(nèi)存設(shè)置為 30GB 到 32GB。

在 Java 中，所有的對象都分配在堆上，并通過一個指針進(jìn)行引用。 普通對象指針（OOP）指向這些對象，通常為 CPU?字長?的大?。?2 位或 64 位，取決于你的處理器。指針引用的就是這個 OOP 值的字節(jié)位置。

對于 32 位的系統(tǒng)，意味著堆內(nèi)存大小最大為 4 GB。對于 64 位的系統(tǒng)， 可以使用更大的內(nèi)存，但是 64 位的指針意味著更大的浪費(fèi)，因?yàn)槟愕闹羔槺旧泶罅?。更糟糕的是?更大的指針在主內(nèi)存和各級緩存（例如 LLC，L1 等）之間移動數(shù)據(jù)的時候，會占用更多的帶寬。

Java 使用一個叫作?內(nèi)存指針壓縮（compressed oops）的技術(shù)來解決這個問題。 它的指針不再表示對象在內(nèi)存中的精確位置，而是表示?偏移量?。這意味著 32 位的指針可以引用 40 億個?對象?， 而不是 40 億個字節(jié)。最終， 也就是說堆內(nèi)存增長到 32 GB 的物理內(nèi)存，也可以用 32 位的指針表示。

一旦你越過那個神奇的 ~32 GB 的邊界，指針就會切回普通對象的指針。 每個對象的指針都變長了，就會使用更多的 CPU 內(nèi)存帶寬，也就是說你實(shí)際上失去了更多的內(nèi)存。事實(shí)上，當(dāng)內(nèi)存到達(dá) 40–50 GB 的時候，有效內(nèi)存才相當(dāng)于使用內(nèi)存對象指針壓縮技術(shù)時候的 32 GB 內(nèi)存。

這段描述的意思就是說：即便你有足夠的內(nèi)存，也盡量不要 超過 32 GB。因?yàn)樗速M(fèi)了內(nèi)存，降低了 CPU 的性能，還要讓 GC 應(yīng)對大內(nèi)存。

ES內(nèi)存使用率 過高的可能因素

索引的大小和數(shù)量：索引的大小和數(shù)量會直接影響 Elasticsearch 使用的內(nèi)存量。較大的索引需要更多的內(nèi)存來處理，而較小的索引則需要較少的內(nèi)存。

查詢負(fù)載：查詢負(fù)載是指 Elasticsearch 在任何給定時刻處理的查詢數(shù)量和類型。更多的查詢負(fù)載需要更多的內(nèi)存來處理和緩存查詢結(jié)果。

JVM 堆內(nèi)存大小：Elasticsearch 在 JVM 堆內(nèi)存中緩存文檔、字段和查詢結(jié)果等數(shù)據(jù)，堆內(nèi)存的大小直接影響 Elasticsearch 的性能。通常，增加堆內(nèi)存大小可以提高 Elasticsearch 的性能，但是在可用內(nèi)存受限的情況下，過大的堆內(nèi)存大小可能會導(dǎo)致系統(tǒng)負(fù)載過重，甚至導(dǎo)致 OutOfMemoryError 錯誤。

硬件資源：Elasticsearch 的內(nèi)存使用率還受限于硬件資源，包括 CPU、磁盤和網(wǎng)絡(luò)帶寬等。如果硬件資源不足，可能會導(dǎo)致 Elasticsearch 性能下降，甚至無法正常運(yùn)行。

Elasticsearch 版本：Elasticsearch 版本之間的內(nèi)存使用率也可能有所不同。較新的版本通常會更有效地利用內(nèi)存，提高性能和穩(wěn)定性。

綜上所述，Elasticsearch 的內(nèi)存使用率受多種因素影響，需要根據(jù)具體情況進(jìn)行分析和調(diào)整，以優(yōu)化性能和穩(wěn)定性。

ES內(nèi)存使用率 過高的處理方案

檢查Elasticsearch集群中是否有索引或搜索查詢的負(fù)載異常，這可能導(dǎo)致內(nèi)存使用率飆升?？梢允褂肊lasticsearch的監(jiān)控工具或REST API來查看負(fù)載和性能指標(biāo)，并識別問題所在。

調(diào)整JVM的堆內(nèi)存大小。JVM是Elasticsearch節(jié)點(diǎn)的內(nèi)存管理器，可以通過調(diào)整JVM的堆內(nèi)存大小來控制Elasticsearch的內(nèi)存使用率?？梢酝ㄟ^在elasticsearch.yml文件中設(shè)置-Xms和-Xmx參數(shù)來增加或減少JVM的堆內(nèi)存大小。注意，不要將JVM的堆內(nèi)存大小設(shè)置過小，否則會影Elasticsearch的性能。

減小索引分片的數(shù)量。索引分片是Elasticsearch的分布式存儲機(jī)制，但太多的分片會占用過多的內(nèi)存資源?？梢酝ㄟ^減小索引分片的數(shù)量來降低內(nèi)存使用率。

使用更高效的查詢。復(fù)雜的查詢可能需要占用更多的內(nèi)存資源，因此，可以嘗試使用更高效的查詢來降低內(nèi)存使用率。例如，使用過濾器而不是查詢語句來獲取數(shù)據(jù)，或使用聚合操作來減少數(shù)據(jù)的返回。

增加硬件資源。如果Elasticsearch集群的內(nèi)存使用率經(jīng)常超過限制，可能需要考慮增加硬件資源，例如增加內(nèi)存或CPU，以滿足集群的性能需求。

?ES內(nèi)存使用率過高，可以考慮調(diào)整哪些參數(shù)：
indices.memory.index_buffer_size：該參數(shù)控制索引模塊使用的內(nèi)存緩沖區(qū)大小。如果內(nèi)存使用率升高，可以嘗試降低該參數(shù)的值，以減少索引模塊占用的內(nèi)存。不過，降低該參數(shù)的值可能會降低索引性能。此參數(shù)應(yīng)該根據(jù)索引的大小和使用情況進(jìn)行調(diào)整。建議將其設(shè)置為每個索引的可用堆內(nèi)存的5%-10%。

indices.fielddata.cache.size：該參數(shù)控制字段數(shù)據(jù)緩存的大小。如果內(nèi)存使用率升高，可以嘗試降低該參數(shù)的值，以減少字段數(shù)據(jù)緩存占用的內(nèi)存。不過，降低該參數(shù)的值可能會降低查詢性能。此參數(shù)應(yīng)該設(shè)置為盡可能大的值，以利用可用的內(nèi)存來緩存字段數(shù)據(jù)。建議設(shè)置為10%-30%的可用堆內(nèi)存。

indices.queries.cache.size：該參數(shù)控制查詢緩存的大小。如果內(nèi)存使用率升高，可以嘗試降低該參數(shù)的值，以減少查詢緩存占用的內(nèi)存。不過，降低該參數(shù)的值可能會降低查詢性能。此參數(shù)應(yīng)該設(shè)置為盡可能大的值，以利用可用的內(nèi)存來緩存查詢。建議設(shè)置為10%-30%的可用堆內(nèi)存。

indices.breaker.*：該參數(shù)控制Elasticsearch使用的熔斷器（circuit breaker）閾值。熔斷器是一種保護(hù)機(jī)制，用于防止過度使用內(nèi)存和磁盤等資源。如果內(nèi)存使用率升高，可以嘗試調(diào)整熔斷器閾值，以避免過度使用內(nèi)存。

indices.recovery.max_bytes_per_sec：該參數(shù)控制恢復(fù)速度。如果內(nèi)存使用率升高，可以嘗試降低該參數(shù)的值，以降低恢復(fù)操作占用的內(nèi)存。 此參數(shù)應(yīng)該根據(jù)網(wǎng)絡(luò)帶寬進(jìn)行調(diào)整，以確保恢復(fù)操作不會占用過多的內(nèi)存。建議將其設(shè)置為網(wǎng)絡(luò)帶寬的70%-80%。

3、ES磁盤使用率

磁盤使用率是指已用磁盤空間和可用磁盤空間之間的比率，通常以百分比形式表示

詳細(xì)說明：
關(guān)于磁盤使用率可詳細(xì)描述的部分較少，這里說明一下常見的幾種磁盤類型：

機(jī)械硬盤（HDD）：機(jī)械硬盤是一種傳統(tǒng)的存儲設(shè)備，使用旋轉(zhuǎn)的磁盤和移動的磁頭來讀寫數(shù)據(jù)。它們相對較便宜，但速度較慢，因此不適合對性能要求較高的應(yīng)用。

固態(tài)硬盤（SSD）：固態(tài)硬盤使用閃存來存儲數(shù)據(jù)，速度比機(jī)械硬盤更快，因此可以提供更好的性能。它們相對較昂貴，但在需要高性能的應(yīng)用場景中通常更受歡迎。

NVMe硬盤：NVMe硬盤是一種專為固態(tài)硬盤設(shè)計(jì)的高速接口，比SATA接口的固態(tài)硬盤更快，因此提供更高的性能。

分布式文件系統(tǒng)：Elasticsearch還支持使用分布式文件系統(tǒng)作為存儲后端，如Hadoop Distributed File System（HDFS）和Amazon S3。這些系統(tǒng)通常用于大規(guī)模數(shù)據(jù)存儲和分析，但也可以用于Elasticsearch。

ES磁盤使用率過高的可能因素

數(shù)據(jù)量：Elasticsearch的磁盤使用率與數(shù)據(jù)量直接相關(guān)，因?yàn)閿?shù)據(jù)存儲在磁盤上。如果數(shù)據(jù)量增加，磁盤使用率也會相應(yīng)增加。

索引設(shè)置：Elasticsearch支持多種索引設(shè)置，如分片和副本，這些設(shè)置會影響數(shù)據(jù)在磁盤上的存儲方式和占用空間的大小。例如，分片數(shù)量越多，每個分片占用的磁盤空間就越小，但需要更多的分片可能會導(dǎo)致額外的磁盤空間占用。

索引更新頻率：當(dāng)索引頻繁更新時，會導(dǎo)致Elasticsearch寫入更多的數(shù)據(jù)到磁盤上，從而增加磁盤使用率。

刪除操作：在Elasticsearch中，刪除文檔不會立即釋放磁盤空間，而是通過后臺的段合并（segment merge）操作來回收空間。如果經(jīng)常刪除文檔，可能需要定期執(zhí)行段合并操作，否則會導(dǎo)致磁盤使用率持續(xù)增加。

數(shù)據(jù)復(fù)制：Elasticsearch支持副本機(jī)制，即將數(shù)據(jù)復(fù)制到其他節(jié)點(diǎn)以實(shí)現(xiàn)高可用性。這意味著每個副本都需要占用額外的磁盤空間。

磁盤類型：不同類型的磁盤對性能和空間占用有不同的影響。例如，固態(tài)硬盤通常比機(jī)械硬盤更快，但通常也更昂貴，而機(jī)械硬盤則更適合低成本應(yīng)用。

ES磁盤使用率磁盤使用率升高時處理方案：
添加更多的節(jié)點(diǎn)：可以通過添加更多的節(jié)點(diǎn)來擴(kuò)展集群的存儲能力，從而減輕單個節(jié)點(diǎn)的負(fù)擔(dān)。

刪除舊的或不需要的數(shù)據(jù)：可以通過刪除舊的或不需要的數(shù)據(jù)來釋放磁盤空間。但是，在刪除數(shù)據(jù)之前，請確保您不再需要這些數(shù)據(jù)，因?yàn)閿?shù)據(jù)刪除是不可逆的操作。

壓縮索引：Elasticsearch提供了一些工具來壓縮索引，可以在不降低性能的情況下減小索引的大小。

增加磁盤空間：如果磁盤使用率升高是由于磁盤空間不足導(dǎo)致的，可以考慮增加磁盤空間。

調(diào)整文檔的存儲方式：可以通過調(diào)整文檔的存儲方式來減小磁盤使用率。例如，可以將文檔中的某些字段設(shè)置為不索引，或者將某些字段設(shè)置為壓縮存儲。

4、ES 中GC頻次

指垃圾回收器在一定時間內(nèi)執(zhí)行的次數(shù)，它是一個反映JVM垃圾回收效率的指標(biāo)。

詳細(xì)說明：
這里指的是老年代的GC頻次，老年代用來存儲較老的對象空間，這些對象預(yù)期是長久的并且持續(xù)了很長時間。在Elasticsearch節(jié)點(diǎn)中最大可以設(shè)置為30GB。

一個緩慢的GC可能有1s甚至15s以上，從集群穩(wěn)定性的角度來說是不可接受的。一個頻繁長時間GC的集群是重負(fù)載并且沒有足夠內(nèi)存的。這些長時間GC將使節(jié)點(diǎn)短暫離開集群，在Elasticsearch中為了保持集群的穩(wěn)定和可用的副本，這種不穩(wěn)定因素經(jīng)常導(dǎo)致重新遷移分片。當(dāng)集群嘗試服務(wù)正常的索引(寫入)和查詢時，會增加網(wǎng)絡(luò)流量和磁盤I/O。

? 在Elasticsearch集群的垃圾回收器替換成G1后，GC的頻次和持續(xù)時間均有明顯改善。

ES 中GC頻次增加的可能因素

JVM堆內(nèi)存不足：當(dāng)JVM堆內(nèi)存不足時，會導(dǎo)致GC頻繁觸發(fā)，以釋放內(nèi)存空間。這種情況通常是由于索引數(shù)據(jù)量增加或者查詢負(fù)載增加等原因?qū)е碌摹?/p>

索引數(shù)據(jù)過多：當(dāng)索引數(shù)據(jù)量過多時，會占用大量的內(nèi)存空間，導(dǎo)致JVM堆內(nèi)存不足，從而引發(fā)GC頻繁觸發(fā)。

查詢壓力過大：當(dāng)查詢壓力過大時，會導(dǎo)致Elasticsearch集群需要處理大量的查詢請求，從而導(dǎo)致JVM堆內(nèi)存不足，引發(fā)GC頻繁觸發(fā)。

代碼邏輯問題：有時候可能存在代碼邏輯問題，例如內(nèi)存泄漏等，也會導(dǎo)致JVM堆內(nèi)存占用過高，從而引發(fā)GC頻繁觸發(fā)。

ES 中GC頻次降低GC頻次的方案

增加JVM堆內(nèi)存大小：GC頻次過高的一個主要原因是JVM內(nèi)存不足，因此增加JVM堆內(nèi)存大小可以有效降低GC頻次。一般來說，JVM堆內(nèi)存大小應(yīng)該設(shè)置為應(yīng)用程序所需要的最小值加上一定的余量，以確保系統(tǒng)具有足夠的內(nèi)存。

優(yōu)化查詢和索引操作：查詢和索引操作是Elasticsearch集群中最耗費(fèi)內(nèi)存和CPU資源的操作，因此可以通過優(yōu)化查詢和索引操作來降低GC頻次。例如，可以使用filter代替query，避免使用過多的聚合操作，避免使用過多的腳本等。

使用合適的垃圾回收器：不同的垃圾回收器有不同的GC算法和優(yōu)化策略，選擇合適的垃圾回收器可以降低GC頻次。一般來說，CMS垃圾回收器比較適合應(yīng)用程序的實(shí)時處理，而G1垃圾回收器則適合大型堆內(nèi)存的應(yīng)用程序。

使用合適的JVM參數(shù)：合適的JVM參數(shù)可以對Elasticsearch集群的GC頻次產(chǎn)生重要影響。例如，可以通過設(shè)置合適的堆內(nèi)存大小、調(diào)整垃圾回收器的參數(shù)等方式來降低GC頻次。

5、ES中fielddata內(nèi)存

fielddata內(nèi)存使用量是指已經(jīng)被加載到內(nèi)存中的fielddata的大小。

詳細(xì)說明：
當(dāng)在Elasticsearch中對一個字段使用聚合、排序、腳本或者用于全文搜索時，該字段的fielddata就會被加載到內(nèi)存中進(jìn)行操作。fielddata是一種用于對文本類型的字段進(jìn)行排序和聚合的數(shù)據(jù)結(jié)構(gòu)。

如果一個集群中有大量的字段需要在內(nèi)存中加載fielddata，那么這個指標(biāo)可能會對集群性能產(chǎn)生負(fù)面影響。因此，需要根據(jù)實(shí)際情況來調(diào)整fielddata的使用策略，以平衡內(nèi)存的使用和查詢性能的需求。

ES中fielddata內(nèi)存使用量增加的可能因素

內(nèi)存不足：當(dāng)fielddata內(nèi)存使用量過高時，可能會導(dǎo)致內(nèi)存不足，從而影響Elasticsearch集群的運(yùn)行。這可能會導(dǎo)致請求被拒絕、節(jié)點(diǎn)故障等問題。

垃圾回收：當(dāng)fielddata內(nèi)存使用量過高時，垃圾回收器會頻繁執(zhí)行，這可能會導(dǎo)致性能下降。特別是在大型集群中，這可能會導(dǎo)致所有節(jié)點(diǎn)的性能下降，進(jìn)而影響整個集群。

磁盤使用量：當(dāng)fielddata內(nèi)存使用量過高時，Elasticsearch可能會將部分?jǐn)?shù)據(jù)寫入磁盤，從而占用更多的磁盤空間。如果磁盤空間不足，可能會影響Elasticsearch集群的穩(wěn)定性。

ES 中fielddata內(nèi)存使用量增高時的解決方案

使用 doc values 替代 fielddata：doc values 是一種結(jié)構(gòu)化的、只讀的數(shù)據(jù)結(jié)構(gòu)，可以直接被用于排序、聚合和腳本，與 fielddata 相比可以減少內(nèi)存使用?？梢允褂?doc_values 屬性將字段顯式地配置為使用 doc values。

避免過度使用 text 類型的字段：text 類型的字段會產(chǎn)生 fielddata，如果不需要進(jìn)行全文搜索、聚合、排序等操作，可以考慮使用 keyword 類型的字段來替代。

減少不必要的聚合操作：聚合操作會對 fielddata 進(jìn)行操作，如果聚合操作不是必須的，可以考慮避免使用。

增加 fielddata 緩存大小：可以通過在配置文件中設(shè)置 indices.fielddata.cache.size 來增加 fielddata 緩存大小，從而減少 fielddata 的內(nèi)存使用。

減少索引的字段數(shù)：減少索引的字段數(shù)可以減少 fielddata 的內(nèi)存使用。

注意，以上優(yōu)化思路需要根據(jù)具體情況來判斷選擇，而ES 官方手冊中建議我們不要輕易去調(diào)整這些配置參數(shù)，因?yàn)檫@些參數(shù)都是基于多年實(shí)際使用中配置好的，換句話說，當(dāng)前集群的性能已經(jīng)可以滿足絕大多數(shù)的使用場景；如果你修改了某些參數(shù)，可能會引發(fā)一些未知問題，從而導(dǎo)致集群處于一個不佳性能的狀態(tài)；而多數(shù)優(yōu)化的前提就是回復(fù)集群原來默認(rèn)配置就可以解決一些性能問題；文章來源地址http://www.zghlxwxcb.cn/news/detail-608401.html

到了這里，關(guān)于【Elasticsearch】 實(shí)際生產(chǎn)中的監(jiān)控及調(diào)優(yōu)的文章就介紹完了。如果您還想了解更多內(nèi)容，請?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！