堆内存应设为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 行为的三方博弈——少一个环节对齐，调参就白做。
