DSE SOLR OOMing

我們有一個3節點的DSE SOLR集羣正在運行，並且最近添加了一個新的核心。大約運行一週後，所有的SOLR節點現在都是OOMing。填充JVM Heap（設置爲8GB）和系統內存。然後也不斷刷新memtables到磁盤。DSE SOLR OOMing

集羣是DSE 3.2.5與RF = 3

這裏是新核心的solrconfig：

http://pastie.org/8973780

來源

2014-03-27 Russ Bradberry

有多大你的Solr相對於系統內存量指數可用於操作系統緩存文件系統頁面。基本上，您的Solr索引需要適合OS文件系統緩存（DSE啓動後可用的系統內存量，但尚未處理任何大量數據）。

此外，有多少個Solr文檔（Cassandra行）和每個節點上填充了多少個字段（Cassandra列）？沒有硬性限制，但是4億到1億是一個很好的指導方針，作爲每個節點的上限。

而且，如果你重新啓動DSE，但你開始把服務器上的負載之前多少JVM堆是多少系統內存和可用？

來源

2014-03-27 18:55:11

如何檢查SOLR索引大小？有3個核心，其中2個文件約3,500萬個，約13個領域，另外約6,500萬個文件和14個領域。我不知道如何在沒有負載的情況下測試服務器，因爲我無法阻止它進行寫操作。 –

無論計算機的計算能力和內存如何，節點大小的上限是40-100m？督察。正在使用更強大的機器不會有所作爲？如果40-100m是帽，是否意味着它是有道理從DSE的Solr/C *性能的角度做出了很多不那麼強大的機器有更多的磁盤空間？ –

這些都不是硬性的限制 - 只是在你需要更加小心之前提供足球指引。有時，更大，更快的機器幫助，但很多時候更小的機器幫助更多Solr的，因爲可以這樣計算和I/O密集型（如果指數不適合在內存中。） –

對於RF = N，其中N是集羣中或至少搜索數據中心節點的總數量，所有的數據將被存儲的所有節點，這是好的爲較小的數據集，但不是好爲較大的數據集。

對於RF = N，這意味着每個節點將具有X/N * n行或文件，其中X是行或文獻中的數據中心中的所有列族的總數。 X/N * n是您應該儘量保持在1億以下的數字。這不是一個硬性的限制 - 一些數據集和硬件可能能夠處理更多，而一些數據集和硬件甚至可能無法承受那麼多。你必須發現最適合你自己應用的數字，但4000萬到1億的範圍是一個好的開始。

總之，最安全的估計爲X/N * n至下40000000爲Solr的節點保持。對於一些數據集和更強大的硬件，100可能會很好。

來源

2014-03-31 17:14:38

至於調諧，使用堆的地段之一公共源是大量使用的solr刻面和過濾器的查詢。

的一種技術是使用「DocValues」字段爲小面因爲DocValues可以存儲關斷堆。

過濾的查詢可以被標記爲緩存=假保存堆內存。

此外，各種Solr的高速緩存可以在尺寸上減少或者甚至設置爲零。這是在solrconfig.xml中。

來源

2014-03-31 22:55:59

回答

相關問題