Elasticsearch 2.4.4连接超时问题求助（EC2部署场景）

结合你遇到的问题和给出的日志，核心问题已经很明确了——JVM老年代内存耗尽导致长时间GC停顿，进而引发节点间通信超时，下面是详细的分析和解决步骤：

问题根源分析 #

从你提供的日志里能看到两个关键信号：

1. 服务日志中的ReceiveTimeoutTransportException：节点间的心跳请求（cluster:monitor/nodes/liveness）超时，这是因为JVM在执行Full GC时出现了6-8秒的Stop-The-World（STW）停顿，超过了Elasticsearch默认的5秒超时阈值，导致集群误判节点失联；
2. Elasticsearch的GC日志显示，老年代内存始终处于满负载状态（[old] [341.3mb]->[341.3mb]/[341.3mb]），说明内存无法有效回收，GC频繁且耗时，这是引发所有问题的核心。

分步解决方案 #

1. 优先调整JVM堆内存配置 #

Elasticsearch 2.x的默认堆配置大概率不匹配你的EC2实例和数据规模（已用94G存储）：

• 修改堆内存大小：Docker部署可以通过环境变量ES_JAVA_OPTS调整，堆内存不要超过物理内存的50%，同时绝对不要超过32GB（超过后JVM压缩指针失效，内存效率骤降）。比如你的EC2实例有8G物理内存，可设置：

  ES_JAVA_OPTS="-Xms3g -Xmx3g"
  

  给系统留足内存用于文件缓存，这对Elasticsearch性能至关重要；
• 优化GC参数：Elasticsearch 2.x默认用CMS收集器，添加以下参数让GC更早触发，避免老年代被填满：

  ES_JAVA_OPTS="-Xms3g -Xmx3g -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=75 -XX:+UseCMSInitiatingOccupancyOnly"
  

2. 检查磁盘与分片配置 #

虽然74%的磁盘使用率还没到Elasticsearch的只读水位线，但大存储占用也会加剧内存压力：

• 执行curl -XGET 'http://<你的ES地址>:9200/_cat/shards?v'查看分片分布，单个分片大小建议控制在20-50GB之间，如果有超过50GB的大分片，考虑拆分索引或调整分片数量；
• 清理过期数据，或者编写脚本定期删除旧索引，减轻节点存储和内存负担。

3. 调整Docker网络与ES超时参数 #

本地环境正常但EC2 Docker出问题，要排查网络和超时设置：

• 确认EC2安全组开放了9300端口（ES节点间通信端口），Docker容器网络模式如果是bridge，要确保容器与宿主机、节点间的9300端口能正常通信；
• 修改Elasticsearch的config/elasticsearch.yml，延长节点间通信超时时间，避免GC停顿导致的误判：

  transport.tcp.connect_timeout: 10s
  transport.tcp.socket_timeout: 10s
  

4. 利用你提到的诊断信息深化排查 #

你说可以提供_cat/fielddata?v和_cat/nodes?v，这两个命令能帮你定位更细节的问题：

• _cat/fielddata?v：查看哪些字段占用了大量内存，如果是text类型字段开启了fielddata，建议关闭或改用doc_values；
• _cat/nodes?v：确认节点的CPU、内存占用情况，看堆内存是否真的足够，以及系统内存是否被其他进程消耗。

临时缓解措施 #

在调整配置的间隙，你可以先做这些操作来临时降低节点压力：

• 暂停非核心的查询/写入请求；
• 执行curl -XPOST 'http://<你的ES地址>:9200/_cache/clear'清理缓存，释放部分内存。

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