0

我有一台将大约 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 没有任何区别。

我正在使用具有 12GB RAM 的 JDK 6.0 和 SUSE x86_64。还有其他进程需要剩余的 RAM，因此实际上不能为此插入任务分配超过 9GB 的空间。

虚拟机：

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)

任何解决此问题的提示表示赞赏。

4

3 回答 3

0

我不希望 JVM 死掉，并建议您尝试稍后（甚至可能更早）的 JVM 版本（我说的是次要版本，例如 JDK1.6.0_21 与 JDK1.6.0._22）以便查看如果您可以避免触发可能是错误的东西。

我的另一个想法是，您可能遇到了 Linux OOM 杀手问题（与内存过度使用有关）。有关更多信息，请参阅此 Serverfault 问题。

于 2011-12-30T10:46:52.873 回答
0

没有适合所有情况的单一解决方案。您将不得不尝试不同的 GC 收集器，以查看哪一个在给定情况下表现最佳。

于 2012-01-10T13:08:02.757 回答
0

虽然这是一个老问题，但最近我遇到了同样的问题。我解决问题的方法是使用 gc 日志分析器（我发现GCeasy很棒）和Eclipse Memory Analyzer来深入了解问题。

然后我发现这个类com.sleepycat.je.tree.BIN几乎占用了JVM的内存。就我而言，JE 的缓存并不那么重要（我的应用是迁移应用）。所以我设置了CashMode.EVICT_BIN我的数据库。

我的意思是，解决方案可能不在于 JVM 选项，而在于应用程序本身。

于 2017-07-12T10:40:00.970 回答