Question

我正在使用Java API运行neo4j 2.3.0-RC1嵌入式。它会在没有警告的情况下继续崩溃，而我正试图找出原因。

我以前使用此代码与1.9.8完全一致。升级到2.0+需要添加事务，改变一些cypher语法，启动时Spring配置，以及一些有限的其他更改。

绝大多数代码保持不变，并且在单元和集成测试中得到确认，功能正确。

引擎启动时，它会在相当稳定的基础上添加新节点。下面的输出显示了290分钟后的一次神秘崩溃。

这似乎总是发生。有时在2小时之后，有时在5之后。1.9.8从未发生过这种情况。

JVM使用./start-engine.sh > console.out 2>&1 &运行。

start-engine.sh的操作行是

$JAVA_HOME/bin/java -server $JAVA_OPTIONS $JPROFILER_OPTIONS -cp '.:lib/*' package.engine.Main $*

以下是console.out的最后几行。

17437.902: RevokeBias                       [     112          6              5    ]      [    20     6    27    43    26    ]  1
17438.020: RevokeBias                       [     112          3              9    ]      [     5     0     5     0     0    ]  3
17438.338: GenCollectForAllocation          [     113          2              2    ]      [     1     0    11     4    32    ]  2
17438.857: BulkRevokeBias                   [     112          3             13    ]      [     0     0    28     6     2    ]  3
./start-engine.sh: line 17: 19647 Killed                  $JAVA_HOME/bin/java -server $JAVA_OPTIONS $JPROFILER_OPTIONS -cp '.:lib/*' package.engine.Main $*

没有堆栈跟踪，也没有其他错误输出。

这些是messages.log

中/mnt/engine-data的最后几行

2015-10-30 18:07:44.457+0000 INFO  [o.n.k.i.t.l.c.CheckPointerImpl] Check Pointing triggered by scheduler for time threshold [845664646]:  Starting check pointing...
2015-10-30 18:07:44.458+0000 INFO  [o.n.k.i.t.l.c.CheckPointerImpl] Check Pointing triggered by scheduler for time threshold [845664646]:  Starting store flush...
2015-10-30 18:07:44.564+0000 INFO  [o.n.k.i.s.c.CountsTracker] About to rotate counts store at transaction 845664650 to [/mnt/engine-data/neostore.counts.db.b], from [/mnt/engine-data/neostore.counts.db.a].
2015-10-30 18:07:44.565+0000 INFO  [o.n.k.i.s.c.CountsTracker] Successfully rotated counts store at transaction 845664650 to [/mnt/engine-data/neostore.counts.db.b], from [/mnt/engine-data/neostore.counts.db.a].
2015-10-30 18:07:44.834+0000 INFO  [o.n.k.i.t.l.c.CheckPointerImpl] Check Pointing triggered by scheduler for time threshold [845664646]:  Store flush completed
2015-10-30 18:07:44.835+0000 INFO  [o.n.k.i.t.l.c.CheckPointerImpl] Check Pointing triggered by scheduler for time threshold [845664646]:  Starting appending check point entry into the tx log...
2015-10-30 18:07:44.836+0000 INFO  [o.n.k.i.t.l.c.CheckPointerImpl] Check Pointing triggered by scheduler for time threshold [845664646]:  Appending check point entry into the tx log completed
2015-10-30 18:07:44.836+0000 INFO  [o.n.k.i.t.l.c.CheckPointerImpl] Check Pointing triggered by scheduler for time threshold [845664646]:  Check pointing completed
2015-10-30 18:07:44.836+0000 INFO  [o.n.k.i.t.l.p.LogPruningImpl] Log Rotation [35826]:  Starting log pruning.
2015-10-30 18:07:44.844+0000 INFO  [o.n.k.i.t.l.p.LogPruningImpl] Log Rotation [35826]:  Log pruning complete.

所以一切都看起来很好，直到崩溃的那一刻，崩溃就完全出乎意料了。

messages.log中有很多其他数据，但我不知道我在寻找什么。

$ java -version
java version "1.7.0_65"
Java(TM) SE Runtime Environment (build 1.7.0_65-b17)
Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)

$uname -a
Linux 3.13.0-65-generic #106-Ubuntu SMP Fri Oct 2 22:08:27 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

Answer 1

您可能会看到Linux内存不足杀手的影响，这会在系统运行物理内存严重不足时终止进程。这可以解释为什么你在日志中找不到任何内容。

引用this excellent article：

因为许多应用程序预先分配内存并经常分配内存不利用分配的内存，内核是用的设计的能够过度提交内存以提高内存使用效率。 ......... 当太多的应用程序开始利用它们被分配的内存时，过度提交模型有时会出现问题，内核必须开始杀死进程......

上面引用的文章是了解OOM Killer的一个很好的资源，并且包含了很多关于如何排除故障并配置Linux以避免问题的信息。

引用this question的答案：

OOM杀手必须选择最佳杀人方法。最好的是指在杀戮时释放最大记忆的过程对系统来说也是最不重要的。

由于neo4j进程很可能是系统上占用内存最多的进程，因此当物理资源开始耗尽时它就会被终止。

避免OOM Killer的一种方法是尝试将其他内存密集型进程保留在同一系统之外。这应该使得记忆过度承诺的可能性大大降低。但你至少应该阅读上面的第一篇文章，更好地了解OOM杀手 - 有很多要知道。

嵌入式neo4j崩溃，没有堆栈跟踪

1 个答案: