直接修改jvm.options中-Xms和-Xmx为相同值（如-Xms512m -Xmx512m），确保不超物理内存50%、单位小写、无空格；优先级上环境变量ES_HEAP_SIZE或命令行参数会覆盖该配置，需检查并清除；同时需调高ulimit -u和vm.max_map_count，并确认目录权限与进程用户一致。
直接改 jvm.options 里的 -Xms 和 -Xmx 就行，但必须设成相同值，且不能超物理内存 50%，否则 Elasticsearch 启动失败或运行卡死。
为什么改了 jvm.options 还不生效？
常见原因不是配置写错，而是启动时被环境变量或命令行参数覆盖。Elasticsearch 会按以下优先级读取堆大小：
- 命令行传入的
-Xms/-Xmx（最高优先级，但宝塔里几乎不用） -
ES_HEAP_SIZE环境变量（中等优先级，适合宝塔部署） -
jvm.options文件内容（默认生效路径，但若前面两项存在，它会被跳过）
宝塔面板下推荐统一走 jvm.options，确保没被其他方式干扰。检查是否在启动脚本或宝塔“守护进程”里额外写了 ES_HEAP_SIZE —— 如果有，删掉或注释掉。
jvm.options 中怎么设 -Xms 和 -Xmx？
打开 /www/server/es-search/config/jvm.options，找到这两行（通常在第20–30行附近）：
-Xms1g -Xmx1g
改成一致的、符合你服务器实际的值，例如 2GB 内存机器建议设为：
-Xms512m -Xmx512m
注意点：
- 单位必须是
m（兆）或g（吉），不能写M或G（大小写敏感） - 数值不能带空格，比如
-Xms 512m是非法语法，会启动报错 - 不要设成
-Xms1g -Xmx2g—— 不同值会导致频繁 GC，搜索延迟飙升 - 如果服务器总内存 ≤ 4GB，
-Xmx别超1g；≤ 2GB 机器建议用512m
改完启动还是报 “unable to create native threads” 或 “memory limit exceeded”？
这往往不是 JVM 堆的问题，而是系统级限制没放开：
- 执行
ulimit -u查用户最大线程数，低配机器常是 1024，不够 ES 启动；临时调高：ulimit -u 65535 - 执行
sysctl vm.max_map_count，ES 要求 ≥ 262144；若不足，运行：sysctl -w vm.max_map_count=262144，并写入/etc/sysctl.conf持久化 - 日志目录（
path.logs）和数据目录（path.data）权限必须属于运行 ES 的用户（如www或你新建的esuser），否则 JVM 初始化阶段就退出，错误日志里看不到堆相关提示
要不要用 ES_HEAP_SIZE 环境变量代替改文件？
可以，但宝塔环境下更易出错。比如你在宝塔终端手动 export ES_HEAP_SIZE=512m，再执行 ./bin/elasticsearch -d，这个变量只对当前 shell 有效；而宝塔“计划任务”或“守护进程”启动时根本读不到。所以除非你明确控制整个启动上下文，否则坚持改 jvm.options 更稳。
真正容易被忽略的是：改完配置后，必须确认 ES 进程已彻底终止（ps aux | grep elasticsearch），再用正确用户重启 —— 残留进程会锁住端口和日志文件，新配置根本不会加载。
