這是一個(gè)關(guān)于我們?nèi)绾卧O(shè)法克服搜索和相關(guān)性堆棧的穩(wěn)定性和性能問(wèn)題的簡(jiǎn)短故事。

語(yǔ)境

在過(guò)去的 10 個(gè)月里，我很高興與個(gè)性化和相關(guān)性團(tuán)隊(duì)合作。我們負(fù)責(zé)根據(jù)排名和機(jī)器學(xué)習(xí)向用戶提供“個(gè)性化和相關(guān)的內(nèi)容”。我們通過(guò)一組提供三個(gè)公共端點(diǎn)的微服務(wù)來(lái)做到這一點(diǎn)，即 Home Feed、Search 和 Related items API。我記得加入團(tuán)隊(duì)幾個(gè)月后，下一個(gè)挑戰(zhàn)是能夠?yàn)楦蟮年P(guān)鍵國(guó)家提供優(yōu)質(zhì)服務(wù)。目標(biāo)是保持我們?cè)谳^小國(guó)家/地區(qū)已經(jīng)擁有的完美性能和穩(wěn)定性。

我們使用 Zookeeper 在 Openshift 上的 AWS 中使用 SolrCloud (v 7.7)。在撰寫(xiě)本文時(shí)，我們很自豪地提到，該 API 每分鐘服務(wù)約 15 萬(wàn)個(gè)請(qǐng)求，并每小時(shí)向我們最大區(qū)域的 Solr 發(fā)送約 21 萬(wàn)個(gè)更新。

基線

在我們最大的市場(chǎng)中部署 Solr 后，我們必須對(duì)其進(jìn)行測(cè)試。我們使用內(nèi)部工具進(jìn)行壓力測(cè)試，我們可以大致獲得所需的流量。我們相信 Solr 配置良好，因此團(tuán)隊(duì)致力于提高客戶端的性能并針對(duì) Solr 設(shè)置更高的超時(shí)時(shí)間。最后我們同意我們可以稍微松散地處理交通。

遷移后

服務(wù)以可接受的響應(yīng)時(shí)間進(jìn)行響應(yīng)，Solr 客戶端表現(xiàn)非常好，直到由于超時(shí)而開(kāi)始打開(kāi)一些斷路器。超時(shí)是由 Solr 副本響應(yīng)時(shí)間過(guò)長(zhǎng)的明顯隨機(jī)問(wèn)題產(chǎn)生的，這些問(wèn)題在沒(méi)有信息顯示的情況下更頻繁地影響前端客戶端。以下是我們遇到的一些問(wèn)題：

• 高比例的副本進(jìn)入恢復(fù)并且需要很長(zhǎng)時(shí)間才能恢復(fù)

• 副本中的錯(cuò)誤無(wú)法到達(dá)領(lǐng)導(dǎo)者，因?yàn)樗鼈兲α?/p>

• 領(lǐng)導(dǎo)者承受過(guò)多的負(fù)載（來(lái)自索引、查詢和副本同步），這導(dǎo)致它們無(wú)法正常運(yùn)行并導(dǎo)致分片崩潰

• 對(duì)“索引/更新服務(wù)”的懷疑，因?yàn)闇p少其到 Solr 的流量會(huì)阻止副本停止或進(jìn)入恢復(fù)模式

• 完整的垃圾收集器經(jīng)常運(yùn)行（老年代和年輕代）。

• 運(yùn)行在 CPU 之上的 SearchExecutor 線程，以及垃圾收集器

• SearchExecutor 線程在緩存預(yù)熱時(shí)拋出異常 (LRUCache.warm)

• 響應(yīng)時(shí)間從 ~30 ms 增加到 ~1500 ms

• 發(fā)現(xiàn)某些 Solr EBS 卷上的 IOPS 達(dá)到 100%

處理問(wèn)題

分析

作為分析的一部分，我們提出了以下主題

Lucene 設(shè)置

Apache Solr 是一個(gè)廣泛使用的搜索和排名引擎，經(jīng)過(guò)深思熟慮并在后臺(tái)使用 Lucene 進(jìn)行設(shè)計(jì)（也與 ElasticSearch 共享）。Lucene 是所有計(jì)算背后的引擎，并為排名和 Faceting 創(chuàng)造了魔力。是否可以對(duì) Lucene 進(jìn)行數(shù)學(xué)運(yùn)算并檢查設(shè)置？我可以根據(jù)大量文檔和論壇閱讀資料分享一個(gè)近似結(jié)果，但是它的配置不如 Solr 的數(shù)學(xué)那么重。
調(diào)整 Lucene 是可能的，前提是您愿意犧牲文檔的結(jié)構(gòu)。真的值得努力嗎？不，當(dāng)您進(jìn)一步閱讀時(shí)，您會(huì)發(fā)現(xiàn)更多信息。

文檔與磁盤(pán)大小

假設(shè)我們有大約 1000 萬(wàn)個(gè)文檔。假設(shè)平均文檔大小為 2 kb。最初，您的磁盤(pán)空間將至少占用以下空間：

分片

一個(gè)集合擁有多個(gè)分片并不一定會(huì)產(chǎn)生更具彈性的 Solr。當(dāng)一個(gè)分片出現(xiàn)問(wèn)題而其他分片無(wú)論如何都可以響應(yīng)時(shí)，時(shí)間響應(yīng)或阻塞器將是最慢的分片。

當(dāng)我們有多個(gè)分片時(shí)，我們將文檔總數(shù)除以分片數(shù)。這減少了緩存和磁盤(pán)大小并改進(jìn)了索引過(guò)程。

索引/更新過(guò)程

是否有可能我們有一個(gè)過(guò)度殺傷的索引/更新過(guò)程？鑒于我們的經(jīng)驗(yàn)，這并不過(guò)分。我將把這個(gè)問(wèn)題的分析留給另一篇文章。否則，這將過(guò)于廣泛。在我們的主要市場(chǎng)，我們已經(jīng)達(dá)到每小時(shí) 21 萬(wàn)次更新（高峰流量）。

Zookeeper

Apache Zookeeper 在此環(huán)境中的唯一工作是盡可能準(zhǔn)確地保持所有節(jié)點(diǎn)的集群狀態(tài)可用。如果副本恢復(fù)過(guò)于頻繁，一個(gè)常見(jiàn)問(wèn)題是集群狀態(tài)可能與 Zookeeper 不同步。這將在正在運(yùn)行的副本之間產(chǎn)生不一致的狀態(tài)，并且嘗試恢復(fù)的副本最終會(huì)進(jìn)入一個(gè)可能持續(xù)數(shù)小時(shí)的長(zhǎng)循環(huán)。Zookeeper 非常穩(wěn)定，它可能僅由于網(wǎng)絡(luò)資源而失敗，或者更好地說(shuō)是缺少它。

我們有足夠的內(nèi)存嗎？

理論

Solr 性能最重要的驅(qū)動(dòng)因素之一是?RAM。Solr 需要足夠的內(nèi)存用于 Java 堆，并需要可用內(nèi)存用于 OS 磁盤(pán)緩存。

強(qiáng)烈建議 Solr 在 64 位 Java 上運(yùn)行，因?yàn)?32 位 Java 被限制為 2GB 堆，這可能會(huì)導(dǎo)致更大的堆不存在的人為限制（在本文后面部分討論） .

讓我們快速了解一下 Solr 是如何使用內(nèi)存的。首先，Solr 使用兩種類型的內(nèi)存：堆內(nèi)存和直接內(nèi)存。直接內(nèi)存用于緩存從文件系統(tǒng)讀取的塊（類似于 Linux 中的文件系統(tǒng)緩存）。Solr 使用直接內(nèi)存來(lái)緩存從磁盤(pán)讀取的數(shù)據(jù)，主要是索引，以提高性能。

當(dāng)它被暴露時(shí)，大部分堆內(nèi)存被多個(gè)緩存使用。

JVM 堆大小需要與 Solr 堆需求估計(jì)相匹配，以及更多用于緩沖目的。堆和操作系統(tǒng)內(nèi)存設(shè)置的這種差異為環(huán)境提供了一些空間來(lái)適應(yīng)零星的內(nèi)存使用高峰，例如后臺(tái)合并或昂貴的查詢，并允許 JVM 有效地執(zhí)行 GC。例如，在 28Gb RAM 計(jì)算機(jī)中設(shè)置 18Gb 堆。

讓我們記住我們一直在為 Solr 改進(jìn)的方程式，與內(nèi)存調(diào)整最相關(guān)的領(lǐng)域如下：

雖然下面的解釋很長(zhǎng)而且很復(fù)雜，但是為了建立另一個(gè)帖子，我仍然想分享我們一直在研究的數(shù)學(xué)。我們?cè)诮鉀Q問(wèn)題之初就使用了自己的計(jì)算器，只是為了實(shí)現(xiàn)后來(lái)在線社區(qū)共享的類似問(wèn)題。
此外，我們確保在啟動(dòng) Solr 時(shí)在 JVM Args 中正確啟用垃圾收集器。

緩存證據(jù)

我們根據(jù) Solr 管理面板中的證據(jù)調(diào)整緩存，如下所示：

• queryResultCache 的命中率為 0.01

• filterCache 的命中率為 0.43

• documentCache 的命中率為 0.01

垃圾收集器和堆

使用 New Relic，我們可以檢查實(shí)例上的內(nèi)存和 GC 活動(dòng)，并注意到 NR 代理由于內(nèi)存閾值而頻繁打開(kāi)其斷路器（淺紅色豎線）：20%；垃圾收集 CPU 閾值：10%。此行為是實(shí)例上可用內(nèi)存問(wèn)題的明確證據(jù)。

我們還可以監(jiān)控一些高 CPU 實(shí)例進(jìn)程，發(fā)現(xiàn)在 searcherExecutor 線程使用 100% 的 CPU 時(shí)占用了大約 99% 的堆。使用 JMX 和 JConsole，我們遇到了包含以下內(nèi)容的異常：
…org.apache.solr.search.LRUCache.warm(LRUCache.java:299) …作為堆棧跟蹤的一部分。上述異常與緩存設(shè)置大小和預(yù)熱有關(guān)。

磁盤(pán)活動(dòng) — AWS IOPS

開(kāi)始解決問(wèn)題

搜索結(jié)果容錯(cuò)

為前端客戶端提供搜索結(jié)果的第一個(gè)想法是始終讓 Solr 副本仍然存在以響應(yīng)查詢，以防集群由于副本處于恢復(fù)甚至消失狀態(tài)而變得不穩(wěn)定。Solr 7 引入了在領(lǐng)導(dǎo)者及其副本之間同步數(shù)據(jù)的新方法：

• NRT 副本：在 SolrCloud 中處理復(fù)制的舊方法。

• TLOG replicas：它使用事務(wù)日志和二進(jìn)制復(fù)制。

• PULL 副本：僅從領(lǐng)導(dǎo)者復(fù)制并使用二進(jìn)制復(fù)制。

長(zhǎng)話短說(shuō)，NRT 副本可以執(zhí)行三個(gè)最重要的任務(wù)，索引、搜索和引導(dǎo)。另一方面，TLOG 副本將以稍微不同的方式處理索引，搜索和引導(dǎo)。差異因素在于 PULL 副本，它只為帶有搜索的查詢提供服務(wù)。

通過(guò)應(yīng)用這種配置，我們可以保證只要分片有領(lǐng)導(dǎo)者，PULL 副本就會(huì)響應(yīng)，從而大大提高可靠性。此外，這種副本不會(huì)像處理索引過(guò)程的副本那樣頻繁地進(jìn)行恢復(fù)。

當(dāng)索引服務(wù)滿負(fù)荷時(shí)，我們?nèi)匀幻媾R問(wèn)題，導(dǎo)致 TLog 副本進(jìn)入恢復(fù)。

調(diào)整 Solr 內(nèi)存

基于這個(gè)問(wèn)題我們是否有足夠的 RAM 來(lái)存儲(chǔ)文檔數(shù)量？，我們決定進(jìn)行實(shí)驗(yàn)。最初的擔(dān)憂是為什么我們?cè)谖臋n的“單位”中配置這些值，如下所示：

根據(jù)之前共享的公式，考慮到我們有 700 萬(wàn)份文檔，估計(jì)的 RAM 約為 3800 Gb。但是，假設(shè)我們有 5 個(gè)分片，那么每個(gè)分片將處理大約 140 萬(wàn)個(gè)直接影響副本的文檔。我們可以估計(jì)，使用該分片配置，所需的 RAM 約為 3420 Gb。這不會(huì)產(chǎn)生根本性的變化，所以我們繼續(xù)前進(jìn)。

緩存結(jié)果

從緩存證據(jù)中，我們可以看到只有一個(gè)緩存被使用得最好，即 filterCache。測(cè)試的解決方案如下：

通過(guò)之前的緩存配置，我們獲得了以下結(jié)果：

• queryResultCache 的命中率為 0.01

• filterCache 的命中率為 0.99

• documentCache 的命中率為 0.02

垃圾收集器結(jié)果

在本節(jié)中，我們可以看到 New Relic 提供的垃圾收集器指標(biāo)。我們沒(méi)有老年代活動(dòng)，通常會(huì)導(dǎo)致 New Relic 代理打開(kāi)它的斷路器（內(nèi)存耗盡）。

磁盤(pán)活動(dòng)結(jié)果

我們?cè)诖疟P(pán)活動(dòng)方面也取得了驚人的成果，索引也大幅下降。

外部服務(wù)結(jié)果

其中一項(xiàng)訪問(wèn) Solr 的服務(wù)在 New Relic 中的響應(yīng)時(shí)間和錯(cuò)誤率顯著下降。

調(diào)整 Solr 集群

多分片模式的一個(gè)缺點(diǎn)是，如果任何副本被破壞，分片領(lǐng)導(dǎo)者將比其對(duì)等節(jié)點(diǎn)花費(fèi)更多的時(shí)間來(lái)回答。這導(dǎo)致分片中最差的時(shí)間響應(yīng)，因?yàn)?Solr 會(huì)在提供最終響應(yīng)之前等待所有分片回答。

為了緩解上述問(wèn)題并考慮到前面描述的結(jié)果，我們決定開(kāi)始逐漸減少節(jié)點(diǎn)和分片的數(shù)量，這對(duì)降低內(nèi)部復(fù)制因子有影響。

結(jié)論

經(jīng)過(guò)數(shù)周的調(diào)查、測(cè)試和調(diào)優(yōu)，我們不僅擺脫了最初暴露的問(wèn)題，而且通過(guò)減少延遲提高了性能，通過(guò)設(shè)置更少的分片和更少的副本降低了管理復(fù)雜性，獲得了對(duì)索引/更新的信任服務(wù)滿負(fù)荷工作，并通過(guò)使用幾乎一半的 AWS EC2 實(shí)例幫助公司減少開(kāi)支。

本文 :https://architect.pub/improving-solr-performance
討論：知識(shí)星球【首席架構(gòu)師圈】或者加微信小號(hào)【ca_cto】或者加QQ群【792862318】
公眾號(hào) ?	【jiagoushipro】 【超級(jí)架構(gòu)師】 精彩圖文詳解架構(gòu)方法論，架構(gòu)實(shí)踐，技術(shù)原理，技術(shù)趨勢(shì)。 我們?cè)诘饶?，趕快掃描關(guān)注吧。
微信小號(hào) ?	【ca_cea】 50000人社區(qū)，討論：企業(yè)架構(gòu)，云計(jì)算，大數(shù)據(jù)，數(shù)據(jù)科學(xué)，物聯(lián)網(wǎng)，人工智能，安全，全棧開(kāi)發(fā)，DevOps，數(shù)字化. ?
QQ群 ?	【285069459】深度交流企業(yè)架構(gòu)，業(yè)務(wù)架構(gòu)，應(yīng)用架構(gòu)，數(shù)據(jù)架構(gòu)，技術(shù)架構(gòu)，集成架構(gòu)，安全架構(gòu)。以及大數(shù)據(jù)，云計(jì)算，物聯(lián)網(wǎng)，人工智能等各種新興技術(shù)。 加QQ群，有珍貴的報(bào)告和干貨資料分享。
視頻號(hào)	【超級(jí)架構(gòu)師】 1分鐘快速了解架構(gòu)相關(guān)的基本概念，模型，方法，經(jīng)驗(yàn)。 每天1分鐘，架構(gòu)心中熟。
知識(shí)星球	【首席架構(gòu)師圈】向大咖提問(wèn)，近距離接觸，或者獲得私密資料分享。	?
喜馬拉雅	【超級(jí)架構(gòu)師】路上或者車上了解最新黑科技資訊，架構(gòu)心得。	【智能時(shí)刻，架構(gòu)君和你聊黑科技】
知識(shí)星球	認(rèn)識(shí)更多朋友，職場(chǎng)和技術(shù)閑聊。	知識(shí)星球【職場(chǎng)和技術(shù)】
領(lǐng)英	Harry	https://www.linkedin.com/in/architect-harry/
領(lǐng)英群組	領(lǐng)英架構(gòu)群組	https://www.linkedin.com/groups/14209750/
微博??	【超級(jí)架構(gòu)師】	智能時(shí)刻?
嗶哩嗶哩	【超級(jí)架構(gòu)師】
抖音	【cea_cio】超級(jí)架構(gòu)師
快手	【cea_cio_cto】超級(jí)架構(gòu)師
小紅書(shū)	【cea_csa_cto】超級(jí)架構(gòu)師	?
網(wǎng)站	CIO(首席信息官)	https://cio.ceo
網(wǎng)站	CIO,CTO和CDO	https://cioctocdo.com
網(wǎng)站	架構(gòu)師實(shí)戰(zhàn)分享	https://architect.pub? ?
網(wǎng)站	程序員云開(kāi)發(fā)分享	https://pgmr.cloud
網(wǎng)站	首席架構(gòu)師社區(qū)	https://jiagoushi.pro
網(wǎng)站	應(yīng)用開(kāi)發(fā)和開(kāi)發(fā)平臺(tái)	https://apaas.dev
網(wǎng)站	開(kāi)發(fā)信息網(wǎng)	https://xinxi.dev
網(wǎng)站	超級(jí)架構(gòu)師	https://jiagou.dev
網(wǎng)站	企業(yè)技術(shù)培訓(xùn)	https://peixun.dev
網(wǎng)站	程序員寶典	https://pgmr.pub? ??
網(wǎng)站	開(kāi)發(fā)者閑談	https://blog.developer.chat
網(wǎng)站	CPO寶典	https://cpo.work
網(wǎng)站	首席安全官	https://cso.pub?????
網(wǎng)站	CIO酷	https://cio.cool
網(wǎng)站	CDO信息	https://cdo.fyi
網(wǎng)站	CXO信息	https://cxo.pub

謝謝大家關(guān)注，轉(zhuǎn)發(fā)，點(diǎn)贊和點(diǎn)在看。文章來(lái)源地址http://www.zghlxwxcb.cn/news/detail-582077.html