es进程 killed by SIGABRT - dumping core

es进程killed by SIGABRT-dumping core

1、ES进程被异常终止，并生成coredump文件

2、经排查分析coredump文件得悉：JVM检测到致命错误，并终止服务。

3、崩溃发生在contiguousspace::block_start_const方法中，这个方法与JVM的垃圾回收机制有关。

4、年轻代Young Generation的垃圾回收持续了704ms，这是一个相对较长的时间，并且在这一秒内只进行了1次GC。

系统记录了GC开销overhead的警告，表明在过去的1秒内，GC花费了相当多的时间。这种情况频繁发生可能会导致系统响应变慢。

5、长时间GC导致的线程异常:

Nul1PointerException发生在Reference Handler线程中，这可能是由于JVM长时间GC导致的线程处理问题。

6、结合coredump分析：

从core dump的日志可以看到，崩溃发生在垃圾回收相关的代码路径中。这与GC日志中的长时间GC警告和高GC开销是一致的。
查看了es的jvm配置等相关信息，可以看到jvm配置的内存32G，但是使用了CMS垃圾回收器，结合前面日志分析，大内存的jvm中，CMS的垃圾回收器配置不当会导致full GC过于频繁而导致长时间的停顿从而导致系统奔溃；从上面的日志分析: 老年代（Old Generation）内存占用高，日志显示老年代内存占用了1.2GB，这表示大部分内存都在老年代。老年代GC（Full GC）如果频繁发生，会导致较长时间的停顿。

现在对es的jvm垃圾回收算法进行了调整,调整为新一代垃圾回收算法: G1 回收算法,后面再做进一步观察,调整后GC算法如下图所示:

总结：

调整GC策略: 使用G1 GC: -xx:+UseG1GC，并调整G1 GC的相关参数：

-XX:+UseG1GC
-XX:MaxGCPauseMillis=200
-XX:InitiatingHeapOccupancyPercent=45

来控制GC停顿时间。