我有一台机器可以将大约502,000,000行插入BDB JE。键和值的示例是：
juhnegferseS0004-47-19332 39694.290336
所有键和值的长度大致相同。 JVM使用以下参数启动：
-Xmx9G -Xms9G -XX:+UseConcMarkSweepGC -XX:NewSize=1024m -server
但是，当它达到~50,000,000行时，JVM被“杀死”（我只是得到消息“被杀”，不知道它是如何/由谁杀死的）。我只是猜测它试图运行垃圾收集然后它无法释放足够的内存或其他东西。但是，有了-Xmx的数量，我猜它应该没有任何问题。
我使用deferredWrites，日志文件的大小设置为100MB。从DPL切换到Base API没有任何区别。
我正在使用JDK 6.0和SUSE x86_64以及12GB的RAM。还有其他进程需要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)
感谢您解决此问题的任何提示。
答案 0 :(得分：0)
我不希望JVM死掉，并且会建议您尝试稍后（或者甚至更早）的JVM版本（我说的是一个次要版本，例如JDK1.6.0_21与JDK1.6.0._22）为了看看你是否可以避免触发可能的错误。
我的另一个想法是，你可能遇到了Linux OOM杀手问题（与内存过量使用有关）。有关详细信息，请参阅this Serverfault question。
答案 1 :(得分：0)
没有一种解决方案适合所有情况。您将不得不尝试不同的GC收集器，以查看在给定情况下哪一个最佳。
答案 2 :(得分：0)
虽然这是一个老问题，但最近我遇到了同样的问题。我为解决我的问题所做的是使用gc日志分析器（我发现GCeasy非常棒），Eclipse Memory Analyzer可以深入了解问题。
然后我发现类com.sleepycat.je.tree.BIN几乎占用了JVM的内存。在我的情况下，JE的缓存不是那么重要（我的应用程序是一个迁移应用程序）。所以我将CashMode.EVICT_BIN设置为我的数据库。
我的意思是解决方案可能不在于JVM选项，而在于应用程序本身。