堆内存应设为min(物理内存50%, 31g)并向下取整到整GB，如64GB机器设31g、32GB设16g；必须同时满足≤31g（保压缩指针）和50%原则（留足Lucene缓存），且需同步配置-Xms/-Xmx一致、bootstrap.memory_lock:true。

直接结论：堆内存设为 -Xms31g -Xmx31g 仅适用于 62GB 及以上物理内存的机器；若物理内存不足 62GB，必须按“50%”向下取整到安全值（如 32GB 机器设为 -Xms16g -Xmx16g），且绝不能突破 31G 上限。

为什么必须同时满足「50%」和「≤31G」两个条件

这两个限制不是并列建议，而是相互制约的硬约束：

• 50% 是为了给 Lucene 的文件系统缓存留足空间——ES 查询性能严重依赖操作系统缓存索引文件（.fdt、.doc 等），这部分缓存不走 JVM 堆，全靠剩余物理内存支撑；
• ≤31g 是为了触发 JVM 的压缩指针（Compressed OOPs）：堆 ≤30.5–31GB 时，JVM 用 32 位偏移量寻址，对象引用占 4 字节；一旦超过（比如设成 -Xmx32g），自动切回 64 位指针，引用变 8 字节，堆内对象实际开销增加约 20%，GC 压力陡增，反而可用内存更少；
• 两者冲突时（例如 128GB 机器，50% = 64GB > 31GB），必须优先服从 31g，此时应部署多个 ES 节点而非单节点堆拉满。

怎么算出你该设多少：分三步手算

别依赖“一半”这种模糊说法，真实配置要落地到具体数字：

• 查物理内存总量：free -h 或 cat /proc/meminfo | grep MemTotal；
• 算 50% 值：比如 64320MB → 32160MB ≈ 31g（注意单位换算，1g = 1024m，别用 1000）；
• 取 min(50% 值, 31g)，并向下对齐到整数 GB（避免小数导致 JVM 计算越界）：  - 64GB 机器 → min(32g, 31g) = 31g → 设 -Xms31g -Xmx31g；  - 32GB 机器 → min(16g, 31g) = 16g → 设 -Xms16g -Xmx16g；  - 16GB 机器 → min(8g, 31g) = 8g → 设 -Xms8g -Xmx8g（低于 16g 时需警惕 fielddata 压力）。

配置时最容易踩的三个坑

这些错误在日志里不会报错，但会默默拖垮集群：

• 在 jvm.options 里只改了 -Xmx31g，漏掉 -Xms31g：JVM 启动时堆从默认 1g 开始动态扩容，扩容过程触发多次 GC，节点启动慢，且初期 heap usage 波动大，监控误报；
• 用环境变量 ES_JAVA_OPTS 覆盖时，忘记注释掉 jvm.options 中原有的 -Xms/-Xmx 行：参数重复加载，JVM 启动失败，报错 Invalid maximum heap size；
• 设完堆后没开 bootstrap.memory_lock: true（elasticsearch.yml）：Linux 内核可能把部分堆页 swap 到磁盘，GC 时触发大量磁盘 IO，查询延迟飙高且不稳定。

真正卡住人的从来不是“设多少”，而是“设完之后有没有让 OS 和 JVM 都按预期交出内存”。31G 不是魔法数字，它背后是压缩指针开关、Lucene 缓存水位、以及 Linux mmap 行为的三方博弈——少一个环节对齐，调参就白做。