Solr的服務器的內存和磁盤空間

Question

語境：

我的磁盤空間

它運行Solr的5.1 AWS EC2實例

• 8GB內存
• 的8Gb。 0與
  • 2048MB的Java堆
  • -Xms2048m -Xmx2048m

  附加：（更新）

  • 日誌是在服務器上生成
  • 進口發生在10S（總是增量）
  • 的間隔從DB導入（JdbcDataSource）
  • 我不認爲我有任何優化目前配置的化策略
  • GC分析？我不知道。
  • 我怎樣才能知道田地有多大？以及什麼是大的？

  現狀：

  上Solr的各項指標200.000文檔和查詢不超過每秒一次。但是，在大約10天內，服務器的內存和的磁盤空間達到可用空間的90％-95％。

  調查磁盤使用情況sudo du -sh /時，它只返回總計2.3G。幾乎不如df -k告訴我的那樣多（Use% -> 92%）。

  我可以通過重新啓動Solr服務來解決這種情況。

  我在想什麼？ Solr如何消耗所有內存和磁盤空間以及如何防止它？

  爲@TMBT

  對不起慢了額外的信息，但我一直在監視Solr的生產服務器的最後幾天。你可以在這裏看到一個綜述： https://www.dropbox.com/s/x5diyanwszrpbav/screencapture-app-datadoghq-com-dash-162482-1468997479755.jpg?dl=0 Solr的當前狀態：https://www.dropbox.com/s/q16dc5t5ctl32od/Screenshot%202016-07-21%2010.29.13.png?dl=0 我在監視開始時重新啓動了Solr，現在，2天后，我看到磁盤空間每天下降1,5Gb。 如果您需要更多細節，請告訴我。

  • 每天都沒有那麼多刪除的文檔。我們正在討論每天50 - 250。
  • 的solr的當前日誌目錄：ls -lh /var/solr/logs - >total 72M
  • 沒有主從設置
  • 進口商不斷運行10秒，但它進口不超過10 - 每次20文檔。每天晚上大量進口3k-4k文檔。當時Solr沒有太多的行動。
  • 沒有大的字段，最大的字段最多可以包含255個字符。

  隨着監測的到位，我測試了最常見的查詢。它確實包含分面（字段，查詢），排序，分組......，但我並沒有真正影響堆和gc計數的各種指標。

Answer 1

我終於設法解決了這個問題。所以我正在回答我自己的問題。

我在位於/var/solr/（本例中爲Solr根位置）的log4j.properties文件中更改/添加了以下行。

# log4j.rootLogger=INFO, file, CONSOLE 
# adding: 
log4j.rootLogger=WARN, file, CONSOLE 

降低日誌記錄級別。

# adding: 
log4j.appender.file.Threshold=INFO 

設置日誌記錄閾值。

您可以在下面的圖表中看到，截至9月2日，磁盤使用情況是穩定的，因爲它應該是。服務器上的內存消耗也是如此。

Answer 2

首先，請訪問your.solr.instance:[port]/[coreName]/admin/system並查看Solr實際使用的資源數量。 memory和system元素將對您最有用。它可能是盒子上的其他東西是至少一些資源使用的罪魁禍首。

對我來說，你可以通過重新啓動Solr尖叫「查詢並導入令人討厭的內存」來解決問題。對於磁盤空間，如果它是後面的日誌文件，我不會感到驚訝。我還想知道，如果由於大量的delta導入問題導致Solr自動刪除它們，您是否會收到大量舊的已刪除文件。實際上，如果您轉到http://your.solr.instance:[port]/solr/#/[coreName]，則應該能夠看到索引中有多少個已刪除的文檔。如果數量非常非常多，則應該在低使用率的時間內安排時間進行優化以擺脫它們。

另外請注意，Solr似乎傾向於儘可能多地填充給定的堆空間。

由於日誌是在服務器上生成的，請檢查它們中有多少個存在。 4.10之後的Solr具有生成大量日誌文件的惡劣習慣，這可能會導致磁盤空間問題，尤其是導入的頻率。有關如何處理Solr對伐木的熱愛的信息，我將參考我的自我回答Solr 5.1: Solr is creating way too many log files。基本上，您需要導航到solr啓動腳本以禁用Solr的日誌備份，然後用您自己的解決方案替換它。

如果您有主從設置，請檢查從服務器是否正在備份某些配置文件，如schema.xml或solrconfig.xml。

根據每個增量導入的記錄數量，您可能會有提交重疊，這會影響您的盒子上的資源使用情況。如果在日誌中讀到任何有關重疊ondecksearchers的信息，這絕對是您的問題。

大量的delta導入也意味着大量的提交。提交是一個相當繁重的操作。你需要在之後調整一些文件之後的軟性提交，並在稍微多一點之後進行硬性提交。如果你批量執行提交，你的頻繁delta應該沒有什麼影響。

如果您要加入用於導入的列，則可能需要爲數據庫中的那些已加入列編制索引。如果您的數據庫與Solr不在同一臺機器上，則網絡延遲是一個可能的問題。這是我過去掙扎過的一個。如果數據庫在同一臺機器上，並且需要索引，那麼不建立索引對您的盒子資源肯定會產生負面影響。

在Solr上使用類似VisualVM的東西來查看堆使用情況和GC可能會有幫助。您希望確保使用量不會迅速增加，並且您還希望確保GC沒有一堆可能會導致您盒子上出現怪異現象的停止收集。

優化是一項非常密集的操作，如果在4.10之後，您應該不需要經常使用該操作。儘管如此，有些人仍然會這樣做，如果你有大量的刪除文件，它可能對你有用。如果您決定採用優化策略，則只應在低使用率時進行，因爲優化會暫時使索引尺寸加倍。優化合並片段並刪除標記爲deltas刪除的文件。

「大字段」是指其中包含大量數據的字段。您需要查看所使用的每種字段類型的大小限制，但是如果您正在朝特定字段的最大大小運行，則可能需要嘗試找到一種方法來減小數據大小。或者，您可以省略將這些大型列導入Solr，而是在從Solr獲取特定文檔後從源DB中的列中檢索數據。這取決於你的設置和你需要什麼。你可能會也可能不會做很多事情。如果你讓所有其他運行更有效率，你應該沒問題。

您運行的查詢類型也會導致您遇到問題。很多排序，刻面等可能會非常耗費內存。如果我是你，我會將VisualVM掛接到Solr，以便我可以觀察堆使用情況和GC，然後使用典型查詢加載測試Solr。