测试Rails应用时Elasticsearch 5.3.3崩溃问题求助

这种情况我在帮客户排查Rails+Elasticsearch问题时碰到过好多次，核心原因基本是ES在测试负载下因为资源不足或配置冲突自行终止，咱们一步步来排查解决：

1. 优先查看Elasticsearch崩溃日志 #

ES崩溃的具体原因几乎都会记录在日志里，Ubuntu Server 14上ES的默认日志路径是/var/log/elasticsearch/elasticsearch.log，用以下命令查看最近的报错信息：

tail -n 50 /var/log/elasticsearch/elasticsearch.log

重点关注ERROR或FATAL级别的日志，内存溢出（OutOfMemoryError）是这个场景下最常见的元凶——ES默认堆内存配置可能过高，当Rails测试占用部分内存后，ES因内存不足被系统强制终止。

2. 调整Elasticsearch堆内存配置 #

ES 5.x的堆内存配置文件在/etc/elasticsearch/jvm.options，找到这两行：

-Xms2g
-Xmx2g

如果你的服务器总内存小于4G，建议把值调低（比如改成512m或1g）：

-Xms512m
-Xmx512m

修改后重启ES服务：

sudo service elasticsearch restart

这一步解决了80%以上类似的ES自行终止问题。

3. 检查Rails测试环境的ES配置 #

有时候测试环境的ES配置会给ES带来额外压力：

• 打开config/environments/test.rb，确认ES的连接配置正确，比如：

  config.elasticsearch.host = 'localhost:9200'
  config.elasticsearch.index_prefix = 'test_' # 避免和生产索引冲突
  

• 如果用RSpec等框架做并发测试，频繁的索引重置/创建可能瞬间压垮ES，可临时改成串行测试（比如添加--seed 1234 --no-parallel参数），观察是否还会崩溃。

4. 调整Ubuntu系统资源限制 #

Ubuntu 14默认的文件句柄数、线程数限制可能不足以支撑ES运行，长期运行后会导致崩溃：

1. 查看当前ES进程的资源限制：

   sudo -u elasticsearch ulimit -a
   

2. 如果open files值小于65535，编辑/etc/security/limits.conf添加：

   elasticsearch soft nofile 65535
   elasticsearch hard nofile 65535
   elasticsearch soft memlock unlimited
   elasticsearch hard memlock unlimited
   

3. 重启ES服务后再测试。

5. 实时监控ES状态 #

在另一个终端窗口实时监控ES健康状态，方便定位崩溃时机：

watch -n 1 curl -s http://localhost:9200/_cat/health?v

跑测试时可以直观看到ES从green状态变为red或直接断开，结合日志能更快锁定问题。

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