在 Elasticsearch 8.1.1 集群实践中，将虚拟机内存从 4G 扩容至 8G 后，成功解决了escluster_es01_1 exited with code 137的启动报错问题。

原因分析

退出代码 137 表明容器收到了 SIGKILL 信号（128+9），进程被强制杀掉。在 Docker Compose version 1.25.0 环境下，这通常由两种情况引发：一是容器内存不足触发 Linux OOM Killer 机制，此时docker inspect显示State.OOMKilled为 true；二是容器收到docker stop信号但应用程序未正常处理 SIGTERM，即使OOMKilled为 false 也会返回 137。

解决方案

1. 确认 OOM 状态

执行docker inspect <ContainerId>查看元数据，若State.OOMKilled属性为 true，则确认为内存不足。若为 false，需检查系统dmesg日志确认是否因 low memory 耗尽导致。

2. 调整容器内存限制

在docker-compose.yml中为服务添加mem_limit参数，例如 Apollo 服务建议限制为400m，Java 一般服务最低限制 300m。对于 Kibana 服务，需在.env 文件中将MEM_LIMIT从 512MB 调回 1GB（即1073741824字节），避免JavaScript heap out of memory错误。

3. 扩容宿主机资源

若未设置内存限制，8G 内存的宿主机最多只能运行约 5 个容器。实际测试中，Elasticsearch 集群在 4G 内存虚拟机无法启动，加到 8G 后正常。也可尝试清理未使用镜像释放空间，命令为docker system prune -a。

注意事项

1. 环境变量类型错误：在.env 文件中设置密码时，若随意设置数字会报错FATAL Error: [config validation of [elasticsearch].password]: expected value of type [string] but got [number]，必须设置为字符串。

2. 信号处理差异：若OOMKilled为 false 但仍报 137，可能是应用未捕获 SIGTERM 信号，需优化代码而非单纯增加内存。

3. 内存区域限制：即使 High Memory 充足，若 Low Memory 耗尽，OOM Killer 依然会杀死进程以保持内核稳定。

参考来源

来源：docker-compose ES8.1.1 集群实践问题总结 - 2022 年 4 月 1 日

来源：解决:Docker Container exited with code 137 - 2022 年 3 月 8 日

来源：没有 OOM 异常时 Docker-compose 退出代码为 137 - 2022 年 11 月 14 日