對(duì)于性能優(yōu)化，升級(jí)硬件設(shè)備配置一直都是提高服務(wù)能力最快速有效的手段。硬件優(yōu)化主要可以從CPU、內(nèi)存、存儲(chǔ)設(shè)備(磁盤)、顯卡、散熱系統(tǒng)、主板、電源、外設(shè)設(shè)備等。
在系統(tǒng)層面能夠影響應(yīng)用性能的一般主要包括三個(gè)因素：CPU、內(nèi)存和 IO(磁盤)?？梢詮倪@三方面進(jìn)行 Elasticsearch 的性能優(yōu)化工作。

一、CPU配置

CPU（中央處理器）是計(jì)算機(jī)系統(tǒng)中最重要的組成部分之一，在CPU內(nèi)可分為兩個(gè)主要的單元，分別是：算數(shù)邏輯單元和控制單元。 它負(fù)責(zé)執(zhí)行計(jì)算機(jī)程序中的指令和控制計(jì)算機(jī)系統(tǒng)的操作。
我們都知道Elasticsearch 是一個(gè)多線程的應(yīng)用程序，而多線程的上下文切換會(huì)導(dǎo)致CPU的繁忙，Elasticsearch 同時(shí)是一個(gè)很消耗內(nèi)存的應(yīng)用程序，特別是在進(jìn)行排序、聚合時(shí)特別吃內(nèi)存，這樣會(huì)導(dǎo)致頻繁的GC，也會(huì)導(dǎo)致CPU比較繁忙。所以合理的CPU的配置可以更好的提升Elasticsearch 的性能。
比如部署Elasticsearch 時(shí)應(yīng)該選擇具有多個(gè)內(nèi)核的現(xiàn)代處理器，常見集群使用2到8核的機(jī)器(建議CPU8核，當(dāng)然具體情況看具體使用)。也可選擇高頻CPU，來提供更快的計(jì)算速度，從而加快Elasticsearch 的處理速度。

注意：更快的 CPUs 和更多的核數(shù)之間選擇，選擇更多的核數(shù)更好。多個(gè)內(nèi)核提供的額外并發(fā)遠(yuǎn)勝過稍微快一點(diǎn)點(diǎn)的時(shí)鐘頻率。

二、內(nèi)存配置

上面說過Elasticsearch 在排序和聚合時(shí)都很耗內(nèi)存，如果有一種資源是最先被耗盡的，它可能是內(nèi)存。所以有足夠的堆空間來應(yīng)付它們是很重要的。即使堆空間是比較小的時(shí)候，也能為操作系統(tǒng)文件緩存提供額外的內(nèi)存。因?yàn)?Lucene 使用的許多數(shù)據(jù)結(jié)構(gòu)是基于磁盤的格式，Elasticsearch 利用操作系統(tǒng)緩存能產(chǎn)生很大效果。這樣顯得內(nèi)存的合理配置比具體配置多少個(gè)（CPU）重要的多得多。

1、內(nèi)存配置總體方針

對(duì)于Elasticsearch 的堆內(nèi)存分配建議將總內(nèi)存的一半分配給堆內(nèi)存，但不要超過機(jī)器的物理限制。對(duì)于數(shù)據(jù)節(jié)點(diǎn)最好不要超過32G，master節(jié)點(diǎn)可適當(dāng)少點(diǎn)(數(shù)據(jù)節(jié)點(diǎn)一半即可)。所以64 GB 內(nèi)存的機(jī)器是非常理想的，但是 32 GB 和 16 GB 機(jī)器也是很常見的。少于8 GB 會(huì)適得其反（你最終需要很多很多的小機(jī)器），大于 64 GB 的機(jī)器也會(huì)有問題(會(huì)有一定浪費(fèi)，成本也會(huì)增加)。

為什么將總內(nèi)存的一半分配給堆內(nèi)存？

答：由于 ES 構(gòu)建基于 lucene，而 lucene 設(shè)計(jì)強(qiáng)大之處在于 lucene 能夠很好的利用操作系統(tǒng)內(nèi)存來緩存索引數(shù)據(jù)，以提供快速的查詢性能。lucene 的索引文件 segements 是存儲(chǔ)在單文件中的，并且不可變，對(duì)于 OS 來說，能夠很友好地將索引文件保持在 cache 中，以便快速訪問；因此，我們很有必要將一半的物理內(nèi)存留給 lucene；另一半的物理內(nèi)存留給 ES（JVM heap）。

為什么數(shù)據(jù)節(jié)點(diǎn)最好不大于32G？

答：在 Elasticsearch 中，將堆內(nèi)存設(shè)置為超過32GB 的主要原因是基于 Java 虛擬機(jī)（JVM）的限制。具體來說，這是由于 JVM 使用指針壓縮技術(shù)所導(dǎo)致的。

• 在 64 位 JVM 中，默認(rèn)開啟了指針壓縮技術(shù)（Compressed Oops），它可以減少指針占用的內(nèi)存空間。指針壓縮適用于堆內(nèi)存小于 32GB 的情況，能夠顯著降低內(nèi)存消耗。然而，當(dāng)堆內(nèi)存超過32GB時(shí)，JVM 不再使用指針壓縮，而是使用全指針模式，這會(huì)增加指針的大小和內(nèi)存開銷。
• 因此，在 Elasticsearch 中，將堆內(nèi)存設(shè)置為超過32GB 時(shí)，可能會(huì)導(dǎo)致更高的內(nèi)存消耗，以及對(duì)垃圾回收（GC）和索引性能的不利影響。這是因?yàn)?code>全指針模式會(huì)增加 GC 操作的時(shí)間和頻率。
• 此外，超過32GB 堆內(nèi)存的配置也可能受到操作系統(tǒng)和硬件的限制。某些操作系統(tǒng)(32位和64位操作系統(tǒng)有不同限制)和硬件可能對(duì)單個(gè)進(jìn)程的可用內(nèi)存有限制，因此超過這些限制可能導(dǎo)致性能問題或運(yùn)行時(shí)錯(cuò)誤。

2、內(nèi)存實(shí)際分配

1）當(dāng)機(jī)器內(nèi)存小于 64G 時(shí)，遵循通用的原則，50% 給 ES，50% 留給 lucene。
2） 當(dāng)機(jī)器內(nèi)存大于 64G 時(shí)，遵循以下原則：

• 如果主要的使用場(chǎng)景是全文檢索，那么建議給 ES Heap 分配 4~32G 的內(nèi)存即可；其它內(nèi)存留給操作系統(tǒng)，供 lucene 使用（segments cache），以提供更快的查詢性能。
• 如果主要的使用場(chǎng)景是聚合或排序，并且大多數(shù)是 numerics，dates，geo_points 以及 not_analyzed 的字符類型，建議分配給 ES Heap 分配 4~32G 的內(nèi)存即可，其它內(nèi)存留給操作系統(tǒng)，供 lucene 使用，提供快速的基于文檔的聚類、排序性能。
• 如果使用場(chǎng)景是聚合或排序，并且都是基于 analyzed 字符數(shù)據(jù)，這時(shí)需要更多的 heap size，建議機(jī)器上運(yùn)行多 ES 實(shí)例，每個(gè)實(shí)例保持不超過 50% 的 ES heap 設(shè)置（但不超過 32 G，堆內(nèi)存設(shè)置 32 G 以下時(shí)，JVM 使用對(duì)象指標(biāo)壓縮技巧節(jié)省空間），50% 以上留給 lucene。

3、禁止swap

禁止 swap，一旦允許內(nèi)存與磁盤的交換，會(huì)引起致命的性能問題?？梢酝ㄟ^在 elasticsearch.yml 中 bootstrap.memory_lock: true，以保持 JVM 鎖定內(nèi)存，保證 ES 的性能。

4、GC設(shè)置

1）GC 默認(rèn)設(shè)置為：Concurrent-Mark and Sweep（CMS），如果數(shù)據(jù)量較大建議改為G1。常用JVM配置如下：

-XX:+UseG1GC → 使用G1 gc

-XX:+ExplicitGCInvokesConcurrent → 提升gc效率,調(diào)用并發(fā)gc，減少gc的STW時(shí)間

-XX:+UseGCOverheadLimit  → 增加gc開銷限制

-XX:MaxGCPauseMillis=200  → 每次GC最大停頓毫秒數(shù)

-XX:InitiatingHeapOccupancyPercent=30  →老年代占比達(dá)到30%，觸發(fā)并發(fā)標(biāo)記

-XX:ParallelGCThreads=43  → gc并行線程數(shù)，只有在 STW階段才有效，不和用戶線程并發(fā)執(zhí)行。一般用于初始標(biāo)記、重新標(biāo)記、清理階段。一般數(shù)值算法是：8+(N-8)*5/8

-XX:ConcGCThreads=8  →并發(fā)標(biāo)記線程數(shù)，并發(fā)標(biāo)記階段，和用戶線程并發(fā)執(zhí)行，如果太大，會(huì)影響用戶線程，造成不穩(wěn)定，一般是ParallelGCThreads的1/4

-XX:G1HeapRegionSize=32m  → 每個(gè)Region（獨(dú)立區(qū)域）的大小，一般是堆內(nèi)存 除以 2048

-XX:+UnlockExperimentalVMOptions  →解鎖實(shí)驗(yàn)參數(shù)

-XX:G1NewSizePercent=10  →年輕代最小占比

-XX:G1MaxNewSizePercent=20  →年輕代最大占比

-XX:G1ReservePercent=25  →年老代預(yù)留空間占比

2）保持線程池的現(xiàn)有設(shè)置，目前 ES 的線程池有了較多優(yōu)化設(shè)置，保持現(xiàn)狀即可；默認(rèn)線程池大小等于 CPU 核心數(shù)。如果一定要改，按公式 ( ( CPU 核心數(shù) * 3 ) / 2 ) + 1 設(shè)置；不能超過 CPU 核心數(shù)的 2 倍； 但是不建議修改默認(rèn)配置，否則會(huì)對(duì) CPU 造成硬傷。

三、IO（磁盤）

硬盤對(duì)所有的集群都很重要，對(duì)大量寫入的集群更是加倍重要（例如那些存儲(chǔ)日志數(shù)據(jù)的）。硬盤是服務(wù)器上最慢的子系統(tǒng)，這意味著那些寫入量很大的集群很容易讓硬盤飽和，使得它成為集群的瓶頸。
在經(jīng)濟(jì)壓力能承受的范圍下，盡量使用固態(tài)硬盤（SSD）。 固態(tài)硬盤相比于任何旋轉(zhuǎn)介質(zhì)（機(jī)械硬盤，磁帶等），無論隨機(jī)寫還是順序?qū)?，都?huì)對(duì) IO 有較大的提升。

如果你正在使用 SSDs，確保你的系統(tǒng) I/O 調(diào)度程序是配置正確的。當(dāng)你向硬盤寫數(shù)據(jù)，I/O 調(diào)度程序決定何時(shí)把數(shù)據(jù)實(shí)際發(fā)送到硬盤。大多數(shù)默認(rèn) *nix 發(fā)行版下的調(diào)度程序都叫做 cfq（完全公平隊(duì)列）。

調(diào)度程序分配時(shí)間片到每個(gè)進(jìn)程。并且優(yōu)化這些到硬盤的眾多隊(duì)列的傳遞。但它是為旋轉(zhuǎn)介質(zhì)優(yōu)化的：機(jī)械硬盤的固有特性意味著它寫入數(shù)據(jù)到基于物理布局的硬盤會(huì)更高效。

這對(duì) SSD 來說是低效的，盡管這里沒有涉及到機(jī)械硬盤。但是，deadline 或者 noop 應(yīng)該被使用。deadline 調(diào)度程序基于寫入等待時(shí)間進(jìn)行優(yōu)化，noop 只是一個(gè)簡單的 FIFO 隊(duì)列。

這個(gè)簡單的更改可以帶來顯著的影響。僅僅是使用正確的調(diào)度程序，我們看到了 500 倍的寫入能力提升

如果你使用旋轉(zhuǎn)介質(zhì)（如機(jī)械硬盤），嘗試獲取盡可能快的硬盤（高性能服務(wù)器硬盤，15k RPM 驅(qū)動(dòng)器）。
使用 RAID0 是提高硬盤速度的有效途徑，對(duì)機(jī)械硬盤和 SSD 來說都是如此。 沒有必要使用鏡像或其它 RAID 變體，因?yàn)?Elasticsearch 在自身層面通過副本，已經(jīng)提供了備份的功能，所以不需要利用磁盤的備份功能，同時(shí)如果使用磁盤備份功能的話，對(duì)寫入速度有較大的影響。
最后，避免使用網(wǎng)絡(luò)附加存儲(chǔ)（NAS）。 人們常聲稱他們的 NAS 解決方案比本地驅(qū)動(dòng)器更快更可靠。除卻這些聲稱，我們從沒看到 NAS 能配得上它的大肆宣傳。NAS 常常很慢，顯露出更大的延時(shí)和更寬的平均延時(shí)方差，而且它是單點(diǎn)故障的。
文章來源地址http://www.zghlxwxcb.cn/news/detail-794591.html

到了這里，關(guān)于Easticsearch性能優(yōu)化之硬件優(yōu)化的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！