Ubuntu20.04 4GB内存运行Elasticsearch8.2被OOM杀死、配置2G堆启动超时怎么办

故障由两个核心问题导致：

1. 内存分配不合理触发系统OOM Killer
   Elasticsearch内存占用分为两部分：JVM堆内存、堆外内存（包含Lucene段缓存、操作系统页缓存、JNI调用开销、网络缓冲区等）。4GB总内存的服务器上，除ES本身外还要给Ubuntu系统基础服务预留至少500MB-800MB内存，堆外内存还要预留和堆内存相当甚至更大的空间。未正确限制堆内存时，ES默认按总内存50%的规则自动分配约2GB堆，运行几小时后堆外内存持续上涨，总内存耗尽触发全局OOM，从日志可以看到被杀时ES的java进程常驻内存已经达到2.3GB，加上其他进程占用完全打满4GB内存。
2. 自定义JVM参数格式错误导致启动超时
   写入的JVM参数使用了双横杠--Xms/--Xmx，属于格式错误，标准JVM内存参数为单横杠开头，JVM无法识别该参数会导致启动流程卡住触发超时。就算参数格式正确，2GB的堆配置对于4GB总内存的机器也过高，没有给堆外和系统预留足够内存，启动阶段申请内存失败也会导致超时。

• 第一步：修正JVM堆内存配置
  测试环境索引数据不足1MB，不需要给ES分配过大堆内存，将堆大小设置为1GB完全足够。编辑/etc/elasticsearch/jvm.options.d/es.options，删除原有错误配置，写入正确参数：

  -Xms1g
  -Xmx1g
  

  注意Xms和Xmx值必须保持一致，避免运行时动态调整堆大小带来的内存波动和性能开销。不要写双横杠，JVM标准参数仅需要单横杠开头。
• 第二步：关闭测试环境非必要功能降低内存开销
  单节点测试场景不需要生产环境的冗余特性，编辑/etc/elasticsearch/elasticsearch.yml加入以下配置，减少不必要的内存占用：

  indices.lifecycle.enabled: false
  xpack.monitoring.collection.enabled: false
  index.number_of_replicas: 0
  

• 第三步：调整systemd启动超时阈值
  低配服务器上ES启动速度较慢，默认的systemd服务超时时间不足会误判启动失败。编辑/lib/systemd/system/elasticsearch.service文件，修改启动超时参数为300秒：

  TimeoutStartSec=300
  

  保存后执行systemctl daemon-reload重载systemd配置。
• 第四步：启动验证
  执行systemctl start elasticsearch启动服务，启动后通过两个维度验证配置生效：
  1. 执行ps aux | grep java查看ES进程启动参数，确认存在-Xms1g -Xmx1g的正确配置
  2. 执行free -h查看系统整体内存占用，正常情况下ES启动后总常驻内存不会超过2GB，预留足够内存余量就不会再触发OOM Killer。

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