现场是这样的。在 CentOS 7.9 上部署 Elasticsearch 7.17，服务启动后立刻退出，日志里是 max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]，机器内存和磁盘都够。
中间走过弯路，把「容器里改了宿主机参数，容器内看到的是命名空间的旧值」当成主因，改完现象没变。
排查方向其实有限，先把可能性排一排。内核默认的 vm.max_map_count 只有 65530，ES 的 mmap 数量远大于这个值；改了 /etc/sysctl.conf 但没有执行 sysctl -p；systemd 的 LimitMEMLOCK 没放开，内存映射先被卡住。
动手时先看当前的限制值
sysctl vm.max_map_count && cat /proc/sys/vm/max_map_count接着写入配置文件并立即加载
echo 'vm.max_map_count = 262144' >> /etc/sysctl.conf && sysctl -p然后把内存锁定限制也放开
grep -nE 'LimitMEMLOCK|LimitNOFILE' /usr/lib/systemd/system/elasticsearch.service等前面都确认过，再重载 systemd 并重启服务
systemctl daemon-reload && systemctl restart elasticsearch手上没有现成的复现脚本，就照着线上请求手工拼了一个。
别只看报错消失，验证要多做一步。Elasticsearch 正常监听 9200，日志里不再出现 max virtual memory areas 的报错，curl 127.0.0.1:9200 返回集群信息。
这里还有个坑。这个参数要改在宿主机内核上，容器里改只是改命名空间；ES 还要求 nofile 到 65536，一起核对比只改一项稳。报错文案容易误导，真正的原因往往在相邻那一层的日志里。