2

Lucene.Netの使用法について調べてから、このディスカッションを開きます。本当に役立つものは何も見つかりませんでした。問題は単純です。Lucene.Netインデックスの構築と更新で問題が発生しています。特に、SetRAMBufferSizeMBを256に、SetMergeFactorを100に、SetMaxMergeDocsを100000に固定しても、メモリ使用量は増え続けます。さらに、インデックスを使用するたびにClose（）メソッドとCommit（）メソッドを慎重に使用します。

lucene.Netを自分のデータで機能させるために、このチュートリアルから始めました：http ://www.lucenetutorial.com/lucene-in-5-minutes.html

10^5および10^6のドキュメントには、1.8GBのRAMが必要なようです。したがって、実際のRAM使用量が7倍以上の場合、なぜSetRAMBufferSizeMBパラメーターを設定する必要があるのでしょうか。誰かが本当にメモリ使用量を制限する方法を知っていますか？

さらに、10^5または10^6のドキュメントを処理するには、x64プラットフォーム用にLucene.Netをコンパイルする必要があることに気付きました。実際、x86プラットフォーム用のコードをコンパイルすると、1.2GBのRAMに体系的にアクセスしてインデックスがクラッシュします。より少ないRAMを使用して、同じ量（またはそれ以上）のドキュメントにインデックスを付けることができる人はいますか？どのハードウェアとソフトウェアの設定ですか？私の環境構成は次のとおりです。--os：=win732/64ビット。--sw：= .Net Framework 4.0 --hw：=6GBのRAMを搭載した12コアのXeonワークステーション。--Lucene.Net rel .: 2.9.4g（現在安定）。-Lucene.Netディレクトリタイプ：FSDirectory（インデックスはディスクに書き込まれます）。

OK、Document / Fieldsインスタンスの再利用に関するアドバイスを使用してコードをテストしましたが、コードはメモリ使用量に関してまったく同じように実行されます。ここでは、ドキュメントのインデックス作成プロセス中に追跡したいくつかのパラメーターのデバッグ行をいくつか投稿し1000000ます。

DEBUG - BuildIndex – IndexWriter - RamSizeInBytes 424960B; index process dimension 1164328960B.  4% of the indexing process.
DEBUG - BuildIndex – IndexWriter - RamSizeInBytes 457728B; index process dimension 1282666496B.  5% of the indexing process.
DEBUG - BuildIndex – IndexWriter - RamSizeInBytes 457728B; index process dimension 1477861376B.  6% of the indexing process.

インデックスプロセスディメンションは、次のように取得されます。

によって利用されるバッファが多かれ少なかれ変更されていない場合でも、プロセスがRAM（インデックス作成プロセスの~1.5GB時点で）どれだけ速く成長するかを簡単に観察できます。したがって、問題は次のとおりです。インデックス作成プロセスサイズの使用を明示的に制限することは可能ですか？検索フェーズ中にパフォーマンスが低下したり、完全なインデックスを待つ必要があるかどうかは関係ありませんが、インデックス作成プロセスがヒットしないこと、または多数のインデックスを作成するスタックオーバーフローエラーが発生しないことを確認する必要があります。ドキュメントの。メモリ使用量を制限することが不可能な場合、どうすればそれを行うことができますか？6%RAMIndexWriterRAMOOM

完全を期すために、デバッグに使用するコードを投稿します。

// get the current process
Process currentProcess = System.Diagnostics.Process.GetCurrentProcess();
// get the physical mem usage of the index writer 
long totalBytesOfIndex = writer.RamSizeInBytes();
// get the physical mem usage
long totalBytesOfMemoryUsed = currentProcess.WorkingSet64;
4

2 に答える 2

4

最後に、バグを見つけました。これは、Luca Gentiliの貢献（http://snowball.tartarus.org/algorithms/italian/stemmer.html）を利用して構築されたItalianAnalyzer（イタリア語のアナライザー）に含まれています。実際、ItalianAnalyzerクラス内では、ストップワードを含むファイルが数回開かれ、使用するたびに閉じられませんでした。これが私にとってOOMの問題の理由でした。このバグの解決Lucene.Netは、インデックスの作成と検索の両方で非常に高速です。

于 2012-09-07T07:44:35.307 に答える
0

SetRAMBufferSizeMBは、IndexWriterをディスクにフラッシュするタイミングを決定する方法の1つにすぎません。XXX MBがメモリに書き込まれ、ディスクにフラッシュする準備ができると、セグメントデータがフラッシュされます。

Luceneには他にもメモリを使用するオブジェクトがたくさんあり、RamBufferとは何の関係もありません。

通常、インデックス作成中にOOMを実行するときに最初に試すことは、Document/Fieldsインスタンスを再利用することです。マルチスレッドのインデックス作成を行う場合は、同じスレッドでのみ再利用するようにしてください。そのため、たまたまOOMを実行しました。そのため、基盤となるIOが非常に高速で、.NETガベージコレクターが作成されたすべての小さなオブジェクトに追いつけない場合です。

于 2012-08-25T02:16:51.923 に答える