SonarQube 6.7.2 LTS启动失败（ES退出码143）原因排查咨询

咱们一步步拆解这个启动失败的问题：首先得明确，进程退出码143对应的是SIGTERM信号（信号编号15），也就是进程被系统终止了——这种情况大概率和资源限制有关，但具体是Elasticsearch（ES）堆内存不足，还是服务器物理内存耗尽，得结合es.log的内容才能精准判断，不过先梳理两种可能性的特征，再给出排查步骤。

两种内存问题的核心区别 #

1. Elasticsearch堆内存不足 #

SonarQube内置的ES有独立的堆内存配置，由sonar.properties文件里的sonar.search.javaOpts参数控制（默认一般是-Xms512m -Xmx512m）。如果堆内存分配过小，ES在启动或初始化时触发内存溢出，会在es.log里明确抛出：

java.lang.OutOfMemoryError: Java heap space
或者 GC overhead limit exceeded

这种情况和服务器总内存够不够无关，纯粹是给ES分配的堆内存不足以支撑其启动需求。

2. 服务器物理内存不足 #

如果服务器的总物理内存被其他进程占满，系统的OOM Killer（内存不足杀手）会主动杀掉占用内存较高的进程（ES就是典型目标）。这种情况下：

• es.log会出现突然中断的日志（没有完整的错误栈）；
• 去系统日志（比如/var/log/messages、dmesg）里找关键词OOM Killer，会看到系统标记杀死ES进程的记录；
• 执行free -h命令查看服务器内存时，会发现available内存几乎耗尽。

必须做的关键排查步骤 #

1. 优先查看es.log
   这个日志文件在SonarQube安装目录的logs子文件夹下，里面的详细报错是定位问题的核心——比如如果是堆内存不足，会有明确的OOM错误；如果是系统资源限制（比如文件描述符不够），也会有对应的提示。

2. 检查ES堆内存配置
   打开sonar.properties，找到sonar.search.javaOpts参数：

   • 如果服务器总内存≥8G，建议调整为-Xms2g -Xmx2g（注意不要超过物理内存的50%，也不要超过32G，因为JVM在32G以上会关闭压缩指针，反而降低性能）；
   • 修改后保存，重启SonarQube试试。

3. 验证其他系统资源限制
   你已经设置了vm.max_map_count=262144，但ES还需要其他系统资源：

   • 文件描述符：执行ulimit -n，确保结果≥65535；
   • 用户线程数：执行ulimit -u，确保结果≥4096；
     如果不满足，可以在sonar.sh里添加对应的配置，或者在/etc/security/limits.conf里全局设置。

4. 检查服务器内存使用情况
   用free -h查看总内存、已用内存、可用内存；用top或htop实时监控内存占用，确认是否有其他进程占用了大量内存。

内容的提问来源于stack exchange，提问作者user7486728