次のオプションを使用して、Tomcat 7およびJava 7内で実行されているsolr 4.1をテストしています
JAVA_OPTS="-Xms256m -Xmx2048m -XX:MaxPermSize=1024m -XX:+UseConcMarkSweepGC -XX:+CMSIncrementalMode -XX:+ParallelRefProcEnabled -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/home/ubuntu/OOM_HeapDump"
ソースコードは次のようになります。
/**** START *****/
int noOfSolrDocumentsInBatch = 0;
for(int i=0 ; i<5000 ; i++) {
SolrInputDocument solrInputDocument = getNextSolrInputDocument();
server.add(solrInputDocument);
noOfSolrDocumentsInBatch += 1;
if(noOfSolrDocumentsInBatch == 10) {
server.commit();
noOfSolrDocumentsInBatch = 0;
}
}
/**** END *****/
メソッド「getNextSolrInputDocument()」は、100 フィールド (平均) の solr ドキュメントを生成します。約 50 のフィールドが「text_general」タイプです。一部の「test_general」フィールドは約 1000 語で構成され、残りは少数の語で構成されます。合計フィールドのうち、約 35 ~ 40 個の多値フィールドがあります (「text_general」タイプではありません)。
すべてのフィールドにインデックスを付けていますが、保存するフィールドは 8 つだけです。これらの 8 つのフィールドのうち、2 つが文字列型、5 つが long、1 つがブール型です。したがって、インデックス サイズはわずか 394 MB です。ただし、OOM 時に占有される RAM は約 2.5 GB です。インデックスのサイズが小さいのに、メモリが非常に多いのはなぜですか? メモリには何が保存されていますか?私たちの理解では、コミットのたびにドキュメントがディスクにフラッシュされるため、コミット後に RAM には何も残らないはずです。
次の設定を使用しています。
server.commit() set waitForSearcher=true and waitForFlush=true
solrConfig.xml has following properties set:
directoryFactory = solr.MMapDirectoryFactory
maxWarmingSearchers = 1
text_general data type is being used as supplied in the schema.xml with the solr setup.
maxIndexingThreads = 8(default)
<autoCommit>
<maxTime>15000</maxTime>
<openSearcher>false</openSearcher>
</autoCommit>
約 3990 の solr ドキュメントをコミットした後、Java heap Out Of Memory Error が発生します。プロファイラーからのメモリ ダンプのスナップショットの一部は、次のリンクにアップロードされています。
http://s9.postimage.org/w7589t9e7/memorydump1.png
http://s7.postimage.org/p3abs6nuj/memorydump2.png
私たちの場合、メモリ消費を最小化/最適化するために何をすべきか、理由を教えてください。また、solrConfig.xml の次のパラメーターの最適な値と理由を提案します。
-
- useColdSearcher - true/false?
- maxwarmingsearchers- 番号 - スペルチェックのオン/オフ?
- omitNorms=true/false?
- TermFreqAndPositions を省略しますか?
-マージファクター?デフォルト値 10 を使用しています
- Java ガベージ コレクション チューニング パラメータ?