java.lang.OutOfMemoryErrorまれな入力ドキュメントに対してエラーをスローする NLP ライブラリ (Stanford NER) を使用しています。
最終的にこれらのドキュメントを分離し、エラーの原因を突き止める予定ですが、これを行うのは困難です (私は Hadoop で実行しているので、スプリット 379/500 などでエラーが 17% 発生することはわかっています)。 . 暫定的な解決策として、この特定の呼び出しに CPU とメモリの制限を適用できるようにしたいと考えています。これを行う最善の方法が何であるかはわかりません。私が最初に考えたのは、1 つのスレッドの固定スレッド プールを作成し、Future で時限 get() を使用することです。これにより、少なくともウォールクロックの制限が得られ、多少役立つ可能性があります.
私の質問は、合理的な量の努力でこれよりもうまくやる方法があるかどうかです.
私は Hadoop に詳しくありませんが、JVM には暗黙的な上限メモリ境界が課されることを忘れないでください (私のメモリが正しければ、サーバーの場合は 64Mb)。JVMが実行しているメモリ構成を確認します（オプションはこちら）
メモリの上限を次のように指定することで、これをオーバーライドできます。
java -Xmx512m
（たとえば）制限を512Mbに設定します。
CPU割り当ての設定はJVMの権限外であり、OS固有のメカニズムになります（できる場合）
これらのジョブを JVM から並行してディスパッチしている場合は、シングルスレッド (または制限付きスレッド) のスレッドプールを実行するとうまくいく可能性があります。ただし、これは実装に依存するため、詳細が必要です。
OutOfMemoryError をキャッチし、どのドキュメントにアクセスしていたかをログに記録してから、次のドキュメントに進みます。ガベージ コレクターは、次のドキュメントに十分なメモリがあることを確認します。
(これは、1 つの文が長すぎたり複雑で解析できない場合に、次の文に移動するためにスタンフォード依存関係パーサーで使用する戦略の 1 つです。)
クラッシュしているドキュメントを特定するだけの場合は、「ドキュメントxをマップしようとしています」というNLPライブラリの呼び出しをログに記録する必要があります。OOMを見ると、マッパーのログに運命の文書が含まれています。あなたが言ったように、あなたはそのドキュメントのどの特性がライブラリをクラッシュさせるのかを決定する必要があります。
私の経験では、特にドキュメントがインターネット上の人々によって作成された場合、どこかにクレイジーで巨大なドキュメントが見つかります。その時点で、そのようなドキュメントをどうするかを決定する必要があります。それらを無視するか、おそらくそれらを切り捨てます。