1膜楷、寫入速度優(yōu)化

在 ES 的默認設置下旭咽，是綜合考慮數(shù)據(jù)可靠性、搜索實時性赌厅、寫入速度等因素的穷绵。當離開默認設置、追求極致的寫入速度時特愿，很多是以犧牲可靠性和搜索實時性為代價的仲墨。

1.1、TranslogFulsh間隔調整

默認情況下揍障，translog持久化策略為每個請求都flush目养，其保證了寫入操作的可靠性。
對應配置為：

index.translog.durability: request

若系統(tǒng)接受一定概率的數(shù)據(jù)丟失毒嫡，如系統(tǒng)日志數(shù)據(jù)等癌蚁，則可以調整translog持久化策略為周期性和一定大小的時候flush。

//設置translog刷盤策略按sync_interval指定的時間周期進行
index.translog.durability: async
//加長translog的刷盤周期兜畸，默認為5s
index.translog.sync_interval: 120s
//超過這個大小會導致refresh操作努释，產(chǎn)生新的Lucene分段。默認值為512MB咬摇。
index.translog.flush_threshold_size: 1024mb

1.2伐蒂、索引刷新間隔

默認索引的refresh_interval為1秒，即數(shù)據(jù)寫入后最長1s就可被搜索到肛鹏，每次索引的refresh會產(chǎn)生一個新的Lucene段逸邦，這會導致頻繁的segment merge行為，如果不需要這么高的搜索實時性在扰，應該降低索引refresh周期缕减。
對應配置：

index.refresh_interval: 120s

1.3、段合并優(yōu)化

段合并scheduler：

//concurrent或serial
index.merge.scheduler.type

serial為串行合并策略健田，此策略下只用一個線程來執(zhí)行段合并任務烛卧。
concurrent為并行合并策略，會創(chuàng)建多個線程來執(zhí)行段合并任務。
默認線程數(shù)為：
Math.max（1, math.min（4,Runtime.getRuntime（）.availableProcessors（） / 2））
可通過設置：index.merge.scheduler.max_thread_count总放，來改變最大線程數(shù)呈宇。

段合并策略：
可通過：index.merge.policy.type來設置合并策略；
主要配置如下：
tiered（分層合并策略）：
ES默認策略局雄，其將大小相似的段放在一起合并甥啄，依據(jù)每層允許的段數(shù)量的最大值，可以區(qū)分出一次合并中段的數(shù)量炬搭。在索引過程中蜈漓，此策略會計算索引中允許存在的段數(shù)量，即為預算宫盔，若索引中段數(shù)量大于預算值融虽，此策略先按段大小降序排序，找出開銷最小的合并方案灼芭，合并的開銷會考慮比較小的段及刪除文檔較多的段有额。如果合并產(chǎn)生的段的大小大于index.merge.policy.max_merged_segment配置，則此合并會減少段合并的數(shù)量彼绷，以保持合并后新的段在預算之內巍佑。

index.merge.policy.expunge_default_allowed：默認為10，指定段刪除文檔的比例寄悯，當刪除文檔比例超過此比例時將會被合并萤衰；
index.merge,policy.max_merge_at_once：指定同一次合并的段的最大數(shù)量，默認為10猜旬。若調大此值脆栋，則一次合并將合并更多段，也會占用更多I/O等系統(tǒng)資源洒擦；
index.merge.policy.max_merge_at_once_explicit：指定對索引進行optimize或expungeDelete操作時一次合并的最大數(shù)量筹吐，默認為30.
index.merge.policy.max_merged_segment：默認5gb，指定索引過程中單個段的最大容量秘遏。
index.merge.policy.segment_per_tier：指定每層段的數(shù)量，默認為10嘉竟。較小的值代理較少的段邦危。同時也意味著更多的合并操作和更低的索引性能。
index.reclaim_deletes_weight：設定刪除文檔在合并操作的重要程度舍扰，默認為2.0倦蚪。若設為0則表示刪除文檔對段合并無影響，值越大表示刪除文檔對段合并影響越大边苹。
index.compund_format：設定lucene中索引是否存儲為壓縮格式陵且，默認為false。若為true，lucene會將索引所有數(shù)據(jù)存儲在一個文檔中慕购，但會降低搜索和索引性能聊疲。
index.merge.async：設定合并操作是否異步進行，默認為true沪悲；
index.merge.async_interval：當index.merge.async為true時获洲，設定兩次合并的間隔時間，默認為1s殿如。

log_byte_size（字節(jié)大小對數(shù)合并策略）：
該策略將創(chuàng)建大小處于對數(shù)運算后大小在指定范圍內的段組成的索引贡珊。當一個新段嘗試并其與其他段不在一個數(shù)量級時，所有處于該數(shù)量級的段就會合并涉馁。索引中段的數(shù)量與經(jīng)對數(shù)運算后新段字節(jié)的大小成比例门岔。此策略通常能在段合并開銷較小的情況下將索引中的段保持在一個較低的水平。

merge_factor：該參數(shù)確定了索引期間索引段以多大的頻率進行合并烤送。該值越小寒随，搜索的速度越快，消耗的內存也越少胯努，而代價則是更慢的索引速度牢裳。如果該值越大，情形則正好相反叶沛，即更快的索引速度（因為索引合并更少）蒲讯，搜索速度更慢，消耗的內存更多灰署。該參數(shù)默認為10判帮，對于批量索引構建，可以設置較大的值溉箕，對于日常索引維護則可采用默認值晦墙。
min_merge_size：該參數(shù)定義了索引段可能的最小容量（段中所有文件的字節(jié)數(shù)）。如果索引段大小小于該參數(shù)值肴茄，且merge_factor參數(shù)值允許晌畅，則進行索引段合并。該參數(shù)默認值為1.6MB寡痰，它對于避免產(chǎn)生大量小索引段是非常有用的抗楔。然而，用戶應該記住拦坠，該參數(shù)值設置為較大值時连躏，將會導致較高的合并成本。
max_merge_size：該參數(shù)定義了允許參與合并的索引段的最大容量（以字節(jié)為單位）贞滨。默認情況下入热，參數(shù)不做設置，因而在索引合并時對索引段大小沒有限制。
maxMergeDocs：該參數(shù)定義了參與合并的索引段的最大文檔數(shù)勺良。默認情況下绰播，參數(shù)沒有設置，因此當索引合并時郑气，對索引段沒有最大文檔數(shù)的限制幅垮。
calibrate_size_by_deletes：該參數(shù)為布爾值，如果設置為true尾组，則段中被刪除文檔的大小會用于索引段大小的計算忙芒。
index.compund_format：該參數(shù)為布爾值，它確定了索引文件是否存儲為復合文件格式讳侨，默認為false呵萨。可參考tiered合并策略配置中該選項的解釋跨跨。

log_doc（文檔對數(shù)合并策略）：
與log_byte_size策略類似潮峦，只不過以文段數(shù)量的計算方式來合并段。

merge_factor：與log_byte_size合并策略中該參數(shù)的作用相同勇婴，請參考前面的解釋忱嘹。
min_merge_docs：該參數(shù)定義了最小索引段允許的最小文檔數(shù)。如果某索引段的文檔數(shù)低于該參數(shù)值耕渴，且- merge_factor參數(shù)允許拘悦，就會執(zhí)行索引合并。該參數(shù)默認值為1000橱脸，它對于避免產(chǎn)生大量小索引段是非常有用的础米。但是用戶需要記住，將該參數(shù)值設置過大會增大索引合并的代價添诉。
max_merge_docs：該參數(shù)定義了可參與索引合并的索引段的最大文檔數(shù)屁桑。默認情況下，該參數(shù)沒有設置栏赴，因而對參與索引合并的索引段的最大文檔數(shù)沒有限制蘑斧。
calibrate_size_by_deletes：該參數(shù)為布爾值，如果設置為true须眷，則段中被刪除文檔的大小會在計算索引段大小時考慮進去乌叶。
index.compund_format：該參數(shù)為布爾值，它確定了索引文件是否存儲為復合文件格式柒爸，默認為false∈屡ぃ可參考tiered合并策略配置中該選項的解釋捎稚。

1.4、indexing buffer

indexing buffer在為doc建立索引時使用，當緩沖區(qū)滿時會刷入磁盤今野，生成一個新的segment葡公，這是除refresh_interval刷新索引外，另一個生成新segment的地方条霜。

//節(jié)點索引緩存的大小催什，默認為整個堆空間的10%
indices.memory.index_buffer_size
//節(jié)點索引緩存的最小值，默認為48MB
indices.memory.min_index_buffer_size
//節(jié)點索引緩存的最大值宰睡，默認為無限制
indices.memory.max_index_buffer_size

1.5蒲凶、使用bulk請求

批量寫比一個索引請求只寫單個文檔的效率高得多，但是要注意bulk請求的整體字節(jié)數(shù)不要太大拆内，太大的請求可能會給集群帶來內存壓力旋圆，因此每個請求最好避免超過幾十兆字節(jié)，即使較大的請求看上去執(zhí)行得更好麸恍。

1.6灵巧、bulk線程池和隊列

建立索引的過程屬于計算密集型任務，應該使用固定大小的線程池配置抹沪，來不及處理的任務放入隊列刻肄。線程池最大線程數(shù)量應配置為CPU核心數(shù)+1，這也是bulk線程池的默認設置融欧，可以避免過多的上下文切換敏弃。隊列大小可以適當增加，但一定要嚴格控制大小蹬癌，過大的隊列導致較高的GC壓力权她，并可能導致FGC頻繁發(fā)生。

1.7逝薪、并發(fā)執(zhí)行bulk請求

bulk寫請求是個長任務隅要，為了給系統(tǒng)增加足夠的寫入壓力，寫入過程應該多個客戶端董济、多線程地并行執(zhí)行步清，如果要驗證系統(tǒng)的極限寫入能力，那么目標就是把CPU壓滿虏肾。磁盤util廓啊、內存等一般都不是瓶頸。如果 CPU 沒有壓滿封豪，則應該提高寫入端的并發(fā)數(shù)量谴轮。但是要注意 bulk線程池隊列的reject情況，出現(xiàn)reject代表ES的bulk隊列已滿吹埠，客戶端請求被拒絕第步，此時客戶端會收到429錯誤（TOO_MANY_REQUESTS）疮装，客戶端對此的處理策略應該是延遲重試。不可忽略這個異常粘都，否則寫入系統(tǒng)的數(shù)據(jù)會少于預期廓推。即使客戶端正確處理了429錯誤，我們仍然應該盡量避免產(chǎn)生reject翩隧。

1.8樊展、自動生成docId

寫入doc時如果外部指定了id，則ES會先嘗試讀取原來doc的版本號堆生，以判斷是否需要更新专缠。這會涉及一次讀取磁盤的操作，通過自動生成doc ID可以避免這個環(huán)節(jié)顽频。

1.9藤肢、調整字段Mappings

減少字段數(shù)量，對于不需要建立索引的字段糯景，不寫入ES嘁圈。
將不需要建立索引的字段index屬性設置為not_analyzed或no。對字段不分詞蟀淮，或者不索引最住，可以減少很多運算操作，降低CPU占用怠惶。尤其是binary類型涨缚，默認情況下占用CPU非常高，而這種類型進行分詞通常沒有什么意義策治。
減少字段內容長度脓魏，如果原始數(shù)據(jù)的大段內容無須全部建立索引，則可以盡量減少不必要的內容通惫。
使用不同的分析器（analyzer）茂翔，不同的分析器在索引過程中運算復雜度也有較大的差異。

1.10履腋、對Analyzed的字段禁用Norms

Norms用于在搜索時計算doc的評分珊燎，如果不需要評分，則可以將其禁用：

＂title＂: {＂type＂: ＂string＂,＂norms＂: {＂enabled＂: false}}

1.11遵湖、index_options 設置

index_options用于控制在建立倒排索引過程中悔政，哪些內容會被添加到倒排索引，例如延旧，doc數(shù)量谋国、詞頻、positions迁沫、offsets等信息芦瘾，優(yōu)化這些設置可以一定程度降低索引過程中的運算任務闷盔，節(jié)省CPU占用率。不過在實際場景中皆尔，通常很難確定業(yè)務將來會不會用到這些信息挨措，除非一開始方案就明確是這樣設計的。

2、搜索速度優(yōu)化

2.1涡戳、為文件系統(tǒng)cache保留足夠內存

應用程序的讀寫都會被操作系統(tǒng)“cache”（除了direct方式）,cache保存在系統(tǒng)物理內存中（線上應該禁用swap），命中cache可以降低對磁盤的直接訪問頻率砸琅。搜索很依賴對系統(tǒng) cache 的命中程剥，如果某個請求需要從磁盤讀取數(shù)據(jù)，則一定會產(chǎn)生相對較高的延遲沐扳。應該至少為系統(tǒng)cache預留一半的可用物理內存泥从，更大的內存有更高的cache命中率。

2.2沪摄、使用更快的硬件

使用SSD會比旋轉類存儲介質好得多躯嫉。盡量避免使用NFS 等遠程文件系統(tǒng)，如果 NFS 比本地存儲慢3倍杨拐，則在搜索場景下響應速度可能會慢10倍左右祈餐。這可能是因為搜索請求有更多的隨機訪問。如果搜索類型屬于計算比較多哄陶，則可以考慮使用更快的CPU帆阳。

2.3、預索引數(shù)據(jù)

可以針對某些查詢的模式來優(yōu)化數(shù)據(jù)的索引方式屋吨。例如蜒谤，如果所有文檔都有一個 price字段，并且大多數(shù)查詢在一個固定的范圍上運行range聚合至扰，那么可以通過將范圍“pre-indexing”到索引中并使用terms聚合來加快聚合速度鳍徽。

PUT index/type/1
{
    ＂designation＂: ＂spoon＂，
    ＂price＂: 13
}

PUT index/type/1
{
    ＂designation＂: ＂spoon＂渊胸，
    ＂price＂: 13旬盯，
    "price_range":"10-100"
}

2.4、字段映射

有些字段的內容是數(shù)值翎猛，但并不意味著其總是應該被映射為數(shù)值類型胖翰，例如，一些標識符切厘，將它們映射為keyword可能會比integer或long更好萨咳。

2.5、優(yōu)化日期搜索

在使用日期范圍檢索時疫稿，使用now的查詢通常不能緩存培他，因為匹配到的范圍一直在變化鹃两。但是，從用戶體驗的角度來看舀凛，切換到一個完整的日期通常是可以接受的俊扳，這樣可以更好地利用查詢緩存。

2.6猛遍、為只讀索引執(zhí)行force-merge

為不再更新的只讀索引執(zhí)行force merge馋记，將Lucene索引合并為單個分段，可以提升查詢速度懊烤。當一個Lucene索引存在多個分段時梯醒，每個分段會單獨執(zhí)行搜索再將結果合并，將只讀索引強制合并為一個Lucene分段不僅可以優(yōu)化搜索過程腌紧，對索引恢復速度也有好處茸习。

2.7、預熱文件系統(tǒng)cache

如果ES主機重啟壁肋，則文件系統(tǒng)緩存將為空号胚，此時搜索會比較慢《栈可以使用index.store.preload設置涕刚，通過指定文件擴展名，顯式地告訴操作系統(tǒng)應該將哪些文件加載到內存中乙帮。

PUT /my_index
{
    ＂settings＂: {
        ＂index.store.preload＂: [＂nvd＂, ＂dvd＂]
    }
}

2.8杜漠、利用自適應副本選擇（ARS）

為了充分利用計算資源和負載均衡，協(xié)調節(jié)點將搜索請求輪詢轉發(fā)到分片的每個副本察净，輪詢策略是負載均衡過程中最簡單的策略驾茴，任何一個負載均衡器都具備這種基礎的策略氢卡，缺點是不考慮后端實際系統(tǒng)壓力和健康水平锈至。
ES的ARS實現(xiàn)基于這樣一個公式：對每個搜索請求，將分片的每個副本進行排序译秦，以確定哪個最可能是轉發(fā)請求的“最佳”副本筑悴。與輪詢方式向分片的每個副本發(fā)送請求不同，ES選擇“最佳”副本并將請求路由到那里突勇。ES7.0開始默認開啟装盯。

PUT /_cluster/settings
{
    ＂transient＂: {
        ＂cluster.routing.use_adaptive_replica_selection＂: true
    }
}

3坷虑、磁盤使用量優(yōu)化

3.1、索引映射參數(shù)

索引創(chuàng)建時可以設置很多映射參數(shù)：

控制字段值是否被索引埂奈。它可以設置為true或false迄损，默認為true。未被索引的字段不會被查詢到账磺，但是可以聚合海蔽。除非禁用doc_values。
doc values：values：默認情況下绑谣，大多數(shù)字段都被索引，這使得它們可以搜索拗引。倒排索引根據(jù)term找到文檔列表借宵，然后獲取文檔原始內容。但是排序和聚合矾削，以及從腳本中訪問某個字段值壤玫，需要不同的數(shù)據(jù)訪問模式，它們不僅需要根據(jù)term找到文檔哼凯，還要獲取文檔中字段的值欲间。這些值需要單獨存儲。doc_values 就是用來存儲這些字段值的断部。它是一種存儲在磁盤上的列式存儲猎贴，在文檔索引時構建，這使得上述數(shù)據(jù)訪問模式成為可能蝴光。它們以面向列的方式存儲與_source相同的值她渴，這使得排序和聚合效率更高。幾乎所有字段類型都支持doc_values蔑祟，但被分析（analyzed）的字符串字段除外（即text類型字符串）趁耗。doc_values默認啟用。
store：默認情況下疆虚，字段值會被索引使它們能搜索苛败，但它們不會被存儲（stored）。意味著可以通過這個字段查詢径簿，但不能取回它的原始值罢屈。

3.2、禁用不需要的特性

禁用norms：
text 類型的字段會在索引中存儲歸一因子（normalizationfactors）牍帚，以便對文檔進行評分儡遮，如果只需要在文本字段上進行匹配，而不關心生成的得分暗赶，則可以配置 ES 不將 norms 寫入索引鄙币。

PUT index
{
    "mappings":{
        "type":{
            "properties":{
                "foo":{
                    "type":"text",
                    "norms":false
                }
            }
        }
    }
}

修改index_options參數(shù)：
text類型的字段默認情況下也在索引中存儲頻率和位置肃叶。頻率用于計算得分，位置用于執(zhí)行短語（phrase）查詢十嘿。如果不需要運行短語查詢因惭，則可以告訴ES不索引位置。
index_options參數(shù)：

docs：只有被索引的文檔數(shù)量绩衷。
freqs：被索引的文檔數(shù)量和索引詞頻蹦魔。索引詞頻用來使重復索引詞的得分高于單個索引詞；
positions：文檔數(shù)量咳燕，詞頻勿决、索引詞位置。位置可用于臨近或短語查詢招盲；
offsets：文檔數(shù)量低缩、詞頻、位置及開始和結束字符偏移量曹货，偏移量可用于高亮顯示咆繁。
字符串使用positions作為默認值，其他字段使用docs為默認值顶籽；

PUT index
{
    "mappings":{
        "type":{
            "properties":{
                "foo":{
                    "type":"text",
                    "index_options":"freqs"
                }
            }
        }
    }
}

3.3玩般、禁用doc values

所有支持doc value的字段都默認啟用了doc value。如果確定不需要對字段進行排序或聚合礼饱，或者從腳本訪問字段值坏为，則可以禁用doc value以節(jié)省磁盤空間：

PUT index
{
    "mappings":{
        "type":{
            "properties":{
                "foo":{
                    "type":"text",
                    "doc_values":false
                }
            }
        }
    }
}

3.4、使用best_compression

_source和設置為＂store＂: true的字段占用磁盤空間都比較多镊绪。默認情況下久脯，它們都是被壓縮存儲的。默認的壓縮算法為LZ4镰吆，可以通過使用best_compression來執(zhí)行壓縮比更高的算法：EFLATE帘撰。但這會占用更多的CPU資源。

PUT index
{
    ＂settings＂: {
        ＂index＂: {
            ＂codec＂: ＂best_compression＂
        }
    }
}

3.5万皿、Fource Merge

一個ES索引由若干分片組成摧找，一個分片有若干Lucene分段，較大的Lucene分段可以更有效地存儲數(shù)據(jù)牢硅。使用_forcemerge API來對分段執(zhí)行合并操作蹬耘，通常，我們將分段合并為一個單個的分段：max_num_segments=1减余。

4综苔、綜合優(yōu)化

4.1、集群層優(yōu)化

4.1.1、規(guī)劃集群規(guī)模

集群規(guī)模和數(shù)據(jù)總量控制：

集群最大規(guī)娜缟福控制在100個節(jié)點左右堡牡，當節(jié)點更多時，節(jié)點間的連接數(shù)和通行量倍增杨刨，主節(jié)點管理壓力較大晤柄；
單個分片不要超過50GB，最大集群的分片總數(shù)控制在幾十萬的級別妖胀，太多分片會增加主節(jié)點管理負擔芥颈，且延長集群重啟恢復時間；
建議為集群配置較好的硬件赚抡，這對搜索性能有較大提升爬坑；另外不要使用不同配置副服務器混合部署，否則搜索取決于最慢的那個節(jié)點涂臣，產(chǎn)生長尾效應妇垢。

4.1.2、多節(jié)點部署

ES不建議為JVM配置超過32GB的內存肉康，超過32GB時，Java內存指針壓縮失效灼舍，浪費一些內存吼和，降低了CPU性能，GC壓力也較大骑素，因此推薦設置為31GB炫乓。確保堆內存最小值（Xms）與最大值（Xmx）大小相同，防止程序在運行時動態(tài)改變堆內存大小献丑，這是很耗系統(tǒng)資源的過程末捣。
當物理內存超過64GB時部署方案：

部署單個節(jié)點，JVM內存配置不超過32GB创橄，配置全部數(shù)據(jù)盤箩做。這種部署模式的缺點是多余的物理內存只能被cache使用，而且只要存在一個壞盤妥畏，節(jié)點重啟會無法啟動邦邦。
部署單個節(jié)點，JVM內存配置超過32GB醉蚁，配置全部數(shù)據(jù)盤燃辖。接受指針壓縮失效和更長時間的GC等負面影響。
有多少個數(shù)據(jù)盤就部署多少個節(jié)點网棍，每個節(jié)點配置單個數(shù)據(jù)路徑黔龟。優(yōu)點是可以統(tǒng)一配置，缺點是節(jié)點數(shù)較多，集群管理負擔大氏身，只適用于集群規(guī)模較小的場景巍棱。
使用內存大小除以64GB來確定要部署的節(jié)點數(shù)，每個節(jié)點配置一部分數(shù)據(jù)盤观谦，優(yōu)點是利用率最高拉盾，缺點是部署復雜。

4.2豁状、節(jié)點層

4.2.1捉偏、控制線程池的隊列大小

不要為bulk和search分配過大的隊列，隊列并非越大越好泻红，隊列緩存的數(shù)據(jù)越多夭禽，GC壓力越大，默認的隊列大小基本夠用了谊路，即使在壓力測試的場景中讹躯，默認隊列大小也足以支持。除非在一些特別的情況下缠劝，例如潮梯，每個請求的數(shù)據(jù)量都非常小，可能需要增加隊列大小惨恭。但是我們推薦寫數(shù)據(jù)時組合較大的bulk請求秉馏。

4.2.2、為系統(tǒng)cache保留一半物理內存

搜索操作很依賴對系統(tǒng)cache的命中脱羡，標準的建議是把50%的可用內存作為ES的堆內存萝究，為Lucene保留剩下的50%，用作系統(tǒng)cache锉罐。

4.3帆竹、系統(tǒng)層

4.3.1、關閉swap

在服務器系統(tǒng)上脓规，無論物理內存多么小栽连，哪怕只有1GB，都應該關閉交換分區(qū)侨舆。當服務程序在交換分區(qū)上緩慢運行時升酣，往往會產(chǎn)生更多不可預期的錯誤，因此當一個申請內存的操作如
果真的遇到物理內存不足時态罪，寧可讓它直接失敗噩茄。一般在安裝操作系統(tǒng)的時候直接關閉交換分區(qū)，或者通過swapoff命令來關閉复颈。

4.3.2绩聘、配置系統(tǒng)的OOM Killer

在Linux下沥割，進程申請的內存并不會立刻為進程分配真實大小的內存，因為進程申請的內存不一定全部使用凿菩，內核在利用這些空閑內存時采取過度分配的策略机杜，假如物理內存為1GB，則兩個進程都可以申請1GB的內存衅谷，這超過了系統(tǒng)的實際內存大小椒拗。當應用程序實際消耗完內存的時候，怎么辦获黔？系統(tǒng)需要“殺掉”一些進程來保障系統(tǒng)正常運行蚀苛。這就觸發(fā)了OOM Killer，通過一些策略給每個進程打分玷氏，根據(jù)分值高低決定“殺掉”哪些進程堵未。默認情況下，占用內存最多的進程被“殺掉”盏触。
如果ES與其他服務混合部署渗蟹，當系統(tǒng)產(chǎn)生OOM的時候，ES有可能會無辜被“殺”赞辩。為了避免這種情況雌芽，我們可以在用戶態(tài)調節(jié)一些進程參數(shù)來讓某些進程不容易被OOM Killer“殺掉”。

4.4辨嗽、索引層

4.4.1世落、Force Merge

對冷索引執(zhí)行Force Merge會有許多好處，可以選擇在系統(tǒng)的空閑時間段對不再更新的只讀索引執(zhí)行ForceMerge召庞。

單一的分段比眾多分段占用的磁盤空間更小一些；
可以大幅減少進程需要打開的文件fd来破；
可以加快搜索過程篮灼，因為搜索需要檢索全部分段；
單個分段加載到內存時也比多個分段更節(jié)省內存占用徘禁；
可以加快索引恢復速度诅诱。

搜索引擎ElasticSearch之（8）、性能優(yōu)化