Berkeley DB JEを実行するための最良のJava optsは何ですか？

Question

BDB JEに約502,000,000行を挿入するマシンがあります。キーと値の例は、次のとおりです。

juhnegferseS0004-47-19332 39694.290336 

すべてのキーと値はおおよそ同じ長さです。 （私はメッセージを取得する「殺した」、どのように/誰が知っていない

-Xmx9G -Xms9G -XX:+UseConcMarkSweepGC -XX:NewSize=1024m -server 

しかし、それは〜5000万行に達したときに、まだ、JVMは「殺される」：JVMは、以下のパラメータで開始されますそれは殺されて欲しい）。私はそれがガベージコレクションを実行しようとしていると思うし、十分なメモリや何かを解放することはできません。しかし、その量の-Xmxでは、問題はないはずです。

私はdeferredWritesを使用し、ログファイルのサイズは100MBに設定されています。 DPLからBase APIへの切り替えは何の違いもありませんでした。

12GBのRAMを搭載したJDK 6.0とSUSE x86_64を使用しています。 RAMの残りを必要とする他のプロセスがあるため、この挿入タスクに実際に9GB以上を割り当てることはできません。

JVM：この問題を修正するための

java version "1.6.0_26" 
Java(TM) SE Runtime Environment (build 1.6.0_26-b03) 
Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode) 

任意のヒントが認識されます。

Answer 1

すべての状況に適した単一の解決策はありません。特定の状況でどのGCが最も優れているかを確認するには、さまざまなGCコレクタを試す必要があります。

Answer 2

私はJVMが死んでしまうとは思っていませんが、後で（あるいはそれ以前の）JVMリリースを試してみることをお勧めします（私はJDK1.6.0_21とJDK1.6.0._22のようなマイナーバージョンを話しています）バグである可能性のあるものを引き起こすのを避けることができるかどうかを確認するためです。

私の他の考えは、Linux OOMキラーの問題（メモリオーバーコミットに関する）に遭遇している可能性があります。詳細はthis Serverfault questionを参照してください。

Answer 3

これは古い質問ですが、最近は同じ問題がありました。私の問題を解決するために何をしているのかは、gcログアナライザ（私はGCeasyがすごいです）と、Eclipse Memory Analyzerを使って問題を深く見ています。

そして、私は、クラスcom.sleepycat.je.tree.BINがJVMのメモリをほとんど消費していることがわかりました。私の場合、JEのキャッシュはそれほど重要ではありません（私のアプリは移行アプリです）。そこで私はデータベースにCashMode.EVICT_BINを設定しました。

私が言っていることは、解決策はJVMのオプションではなく、アプリケーション自体にあるということです。