Web アプリケーションで Stanford NER を使用しており、english.muc.7class.distim.crf.ser.gz (16 MB サイズ) を分類子として使用しています。アプリケーションをデプロイして実行しようとすると、ヒープ スペースが発生します - メモリ不足です分類子の読み込み中にエラーが発生しました。
コードがあまりにも多くのオブジェクトを作成してスペースを占有していないかどうかもチェックして、有用なコードのみを維持しようとしました。しかし、成功しません。
分類子のサイズのせいですか？同じものを使いたいのですが、どうすればいいですか？
Tomcat で vm オプションを使用してローカルでヒープ サイズを増やしました。しかし、アプリケーションをホストする実際のサーバーで vm のヒープ サイズを増やすことができますが、それも正しい方法ではありません。
誰でもこれについて私を案内できますか?
はい、コードのサイズはロードされるデータのサイズに支配されるため、基本的にコードのサイズについてあまり心配する必要はありません。
モデル データ: 分類子モデルは多くのスペースを必要とします。現行 (2012) バージョンの english.muc.7class.distim.crf.ser.gz をロードするには、約 140 MB のヒープが必要なようです。それらはたくさんの String と double ですが、ディスク上のサイズが大きく増加する理由は、よく知られているように、ディスク上のデータが圧縮されているためです。Java の String オブジェクトはそれぞれ膨大な量のスペースを必要とし、より多くのスペースを必要とする HashMap を介して再リンクされます。String データだけで約 72 MB のメモリが必要になるようです (36 MB の char[] データ、36 MB の String オブジェクト)。
分析するデータ: これは呼び出し方によって異なり、Tomcat の場合は問題にならない場合がありますが、NER がファイルに対して実行されている場合、分類する前にファイル全体がメモリに読み込まれます。したがって、分類する複数の小さな単位 (ファイル、文字列など) を指定することで、メモリを削減できます。
また、タグstanford-nlpを使用すると、このような質問に対して迅速なヘルプが得られる可能性が高くなります。
クリストファーの提案に同意します。サイズについて心配する必要はありません。
ただし、堅牢なパフォーマンスを得るには、永久に有効な Java スレッドを使用し、静的メソッドまたはリスナーを介して serevr の開始時に一度だけ分類子をロードするようにしてください。その後、さらに注釈を付けるには、同じコンテキストを使用します。