java – 没有stacktrace的嵌入式neo4j崩溃
作者：互联网
我正在使用Java API运行neo4j 2.3.0-RC1.它在没有警告的情况下继续崩溃,我正在试图找出原因.
我以前使用这个代码就好了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 $*
没有堆栈跟踪,也没有其他错误输出.
这些是/ mnt / engine-data中的最后几行messages.log
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
解决方法:
您可能会看到Linux Out-of-Memory Killer的影响,当系统运行物理内存严重不足时,它会终止进程.这可以解释为什么您在日志中找不到任何内容.
Because many applications allocate their memory up front and often
don’t utilize the memory allocated, the kernel was designed with the
ability to over-commit memory to make memory usage more efficient.
………
When too many applications start utilizing the memory they were allocated, the over-commit model sometimes becomes problematic and the kernel must start killing processes …
上面引用的文章是了解OOM Killer的一个很好的资源,并且包含了很多关于如何排除故障并配置Linux以试图避免问题的信息.
并引用this question的答案：
The OOM Killer has to select the best process to kill. Best here
refers to that process which will free up maximum memory upon killing
and is also least important to the system.
由于neo4j进程很可能是系统上占用内存最多的进程,因此在物理资源开始耗尽时它会被终止.
避免OOM Killer的一种方法是尝试将其他内存密集型进程保留在同一系统之外.这应该使得记忆过度承诺的可能性大大降低.但你至少应该阅读上面的第一篇文章,更好地了解OOM杀手 – 有很多要知道.
标签：java,neo4j,jvm-crash 来源： https://codeday.me/bug/20190528/1168670.html