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

Question

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

我以前使用此代码就好了1.9.8.升级到2.0+需要添加事务,更改一些密码语法,启动时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 Out-of-Memory Killer的影响,当系统运行物理内存严重不足时,它会终止进程.这可以解释为什么您在日志中找不到任何内容.

引用这篇优秀的文章:

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

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

并引用这个问题的答案:

OOM杀手必须选择最好的杀人程序.这里最好的是指在杀死时释放最大内存的过程,对系统来说也是最不重要的.

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

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