如何針對生產調整Apache Solr 的內存

正確配置Apache Solr內存對於生產系統的穩定性和性能至關重要。在相互矛盾的目標之間找到平衡點真的很難。還需要考慮隱含的或明確的多個因素。這篇文章介紹了內存調優的一些常見任務，並指導您完成該過程，以幫助您了解如何為生產系統配置Solr內存。

為了操作簡單起見，這篇文章採用在HDFS上運行的Cloudera CDH5.11中的Solr。 該平台依賴於oracle jdk8和64位Linux。這篇文章分為兩部分。

內存調優的常見任務

在詳細介紹之前，讓我們來看一下在內存調優需要解決的基本問題。為了避免JVM內存不足（OOM）或巨大的GC開銷，內存調優的首要任務是JVM堆大小必須與Solr的內存需求相匹配。JVM堆大小的設置很簡單。在Solr中配置配置（Cloudera Manager -> Solr configuration -> heap size）。另一方面，Solr的內存需求差異取決於索引大小、工作負載和配置。本文將向您展示如何正確估算索引大小、工作負載和配置，這樣您就可以匹配JVM堆大小和Solr內存需求。

內存調優的另一個常見任務是找到內存使用情況和性能之間的最佳平衡點。 通常，Solr的內存越多，實施越好，但並不總是這樣。另一方面，給出的內存越多，硬體成本越高，JVM GC開銷越大。平衡點是一個固定的點，如果給出的內存大於最佳平衡點，則性能改進不能再使這些弊端被合理化接受。在本文中，我們將向您展示一些案例關於如何在選擇最佳堆大小時找到最有效的點，以及一些其他通用優化Solr的最佳實踐。

JVM GC調優也是一種常見的任務。 一般Solr對GC都是很友好的，在大多數情況下無需太多調整 。該博客將涵蓋幾個可以提高Solr性能的最關鍵的GC調整旋鈕。

Solr如何使用內存

在我們開始評估Solr內存需求之前，我們先看一下Solr如何使用內存。Solr使用的兩種內存類型是堆內存和直接內存（通常稱為off-heap。直接內存用於緩存從文件系統讀取的塊，類似於Linux文件系統緩存。針對堆內存，下圖顯示了Solr中不同類型的主要用戶。

如您所見，多個緩存在使用大部分的堆內存，除了欄位緩存以外，其他緩存都在per core中。Solr 內核是索引的一部分。 Solr伺服器通常有多個內核。緩存能使用的最大內存由配置在solrconfig.xml中的單個緩存大小控制。

開始使用

調整之前，請確保您的系統在索引大小和工作負載方面的平衡。例如，使用shard router、或可以在生產工作負載下創建大小相等集合和內核的collection alias。還要確保所有的內核在所有節點上均勻分布。如果您想了解有關平衡設計的更多細節，請留意未來Cloudera工程博客。

由於Solr內存需求取決於索引大小、工作負載，而在所有Solr節點上均勻的分布索引和工作負載，大大簡化了內存調整 ，避免了所有單個節點的瓶頸，最終還有助於系統性能的穩定性。該示例假設、在所有Solr節點之間均勻的分布了索引和工作負載。

而第一步在生產中部署Solr ，使用一組「safe」配置參數啟動Solr是個不錯的方法。可能這種方法性能不是最好的，但是能確保Solr的穩定性，並為將來的調整打下堅實的基礎。這裡介紹幾個用於開始的調整旋鈕，其中一些將在本文第2部分的調優部分再次提到。

JVM堆大小

如上所述，JVM堆大小應符合Solr堆的需求，可以如下去評估。

如果cache auto warm被使用了，請使用cache size + cache autowarm size替換cache size。

在Solr中主要是Field cache消耗內存。要避免這種情況， 並減少內存佔用的最佳方法是使用docValues。以下部分將更多的細節介紹。在 field緩存被使用了的情況下，如果faceting的工作負載很重並且單值field分類和索引尺寸很大（> 50M文檔或> 10G大小），則可以粗略估算使用8-12G用於field 緩存。要不然4-8G就可以。 Field值緩存用於faceting、排序用於多值multi-valued並遵循與Field緩存類似的指導。

評估JVM堆大小需要匹配Solr堆需求和一些緩衝區。理想情況下，30％的緩衝空間有利於生產系統。這些緩存可以容納零星內存的usage spike，例如後台合并或偶爾高消耗的查詢，並允許JVM有效執行GC。針對生產系統，如果你要增加內存的話，建議使用的堆的最小尺寸16G。

堆外內存（直接內存）

Solr使用堆外內存緩存從磁碟讀取的數據，大部分索引用於改善性能。堆外內存不會導致任何JVM GC開銷，可以使用CM設置堆外內存大小（Cloudera Manager->Solr configuration->direct memory）。根據經驗來看，如果docValues不在模式中使用，推薦使用的堆外內存的最小尺寸為8G，如果使用docValues，則為12-16G。其他相關配置是塊緩存計數器（Cloudera Manager-> Solr configuration-> slab count），而塊緩存計數器需要匹配堆外內存大小的。

垃圾收集器

當CMS和G1 GC都支持Oracle JDK 8的時候。根據經驗，如果堆大小小於28G，而CMS工作良好。其實G1便是更好的選擇。如果您選擇G1，本文的第2部分有更多關於配置G1的詳細信息。 您還可以在Oracle G1調優指南中找到有價值的指導方法。

同時，啟用GC日誌一直都是一個不錯的辦法，因為GC日誌的開銷微乎其微，但它使我們更好地了解JVM如何在Hood中使用內存。而這些信息在GC故障排除中至關重要。 以下是GC日誌設置的示例。

在上面的示例中，GC日誌存儲在/var/log/solr/solr_gc.log中。 您可以將GC日誌指向任何路徑。由於Solr在CDH中的Linux user「solr」下運行，只需確保Linux user「solr」是否已經對您指向的路徑具有許可權。

架構

如果您的工作負載在facet和某些fields的排序很重，請對這些fields使用docValues。使用docValues Solr可以避免在堆上使用 field緩存和 field值緩存，這就大大降低了堆和JVM GC的內存壓力。另一方面，正如上面堆外內存部分所述的一樣，docValue fields可能會導致更多的磁碟I / O影響性能，並且需要大量的堆外內存。

當field用於faceting和排序時，文本field可能會導致大量內存使用。 在這種情況下使用string field代替文本field。

監控

Monitoring是跟蹤系統健康的主要手段之一。一般情況下，良好的監控四個組成部分：關鍵指標，儀錶板，日誌和警報。本文將介紹內存相關的關鍵指標和儀錶板。

關鍵指標

以下是要監視的關鍵指標的列表。 指標分為兩類：JVM metrics和緩存metrics。

Jvm_heap_used_mb告訴我們多少heap Solr 在JVM中實際使用。以及它應該在JVM Heap Size 節圍繞中上下部分評估Solr內存需求。 Cloudera經理每分鐘收集一個樣本。因此，這種指標可能不會反映所有內存使用率上升。如前所述，確保堆內有足夠的緩衝區內存，以容納零星的內存使用率上升並降低GC開銷。

緩存命中率是監視的另一個關鍵指標。它表示通過緩存而不是在磁碟命中索引來滿足（或部分滿足）總查詢之外的請求數量。由於命中索引成本高，高速緩存命中率意味著緩存能滿足更多的請求，這對性能有好處。本文第2部分的緩存優化部分有更多關於的緩存命中率的細節。

儀錶板

監控這些關鍵指標的最簡單方法是CM儀錶板。您可以針對每一個指標的使用查詢，利用Cloudera Manager輕鬆的創建一個儀錶板，類似以下表格中的樣本。

這是從上面的查詢創建的儀錶板。

實時指標值和長期趨勢都很重要。實時值顯示Solr是如何執行的。如果系統發生變化那麼長期趨勢就會預示，如工作量，索引大小等，當您在查看長期趨勢時，CM儀錶板將執行降低採樣。例如，如果您查看30天期間的JVM heap使用情況，儀錶板顯示三個值max，min，mean。 針對JVM堆使用，將監控平均值的最大值。

結論

內存調整是將Solr帶入生產的關鍵步驟。Solr中有許多調整旋鈕可以幫助您設置性能穩定的實施系統。本文介紹了：通用的內存調優技術，一些調整旋鈕，如何通過一組注重是穩定性的配置啟動您的第一個生產部署。該博客還介紹了Solr內存監控，這對於確保您的Solr部署在一段時間內的穩定運行至關重要。

現在我們有一個穩定運行的 Solr。 本文的第2部分將深入展示如何調整內存，獲得更多Solr之外的內存以及如何調整GC。第2部分中還描述的最佳實踐方法。

第二部分最佳實踐內容，將在後續持續更新。

說明：由於是工作之餘進行維護，不能每天持續更新，但定會保證文章的質量和原創性。相關最佳實踐系列，下一階段開啟BigData系列內容，敬請期待。

參考:

[1]. apache-solr-memory-tuning-for-production

[2]. solr-memory-tuning-for-production-part-2

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！