问题出现得很突然，日志倒是留得挺全。用 docker 起 Elasticsearch 7.10，容器日志反复刷 max virtual memory areas vm.max_map_count [65530] is too low，容器起来十几秒就退出，宿主机内存还有十几 G。
刚开始盯着「改了宿主机参数但没重启容器，进程启动时读到的还是旧值」，折腾了半个多小时，排掉了。
排查方向其实有限，先把可能性排一排。每个 mmap 段都占一个 map count，ES 的索引文件多，默认六万多很容易用尽。另一种情况是docker 容器继承宿主机的内核参数，容器内改 /etc/sysctl.conf 对宿主机无效。
不容易想到的是，systemd 服务与命令行参数冲突，容器运行时覆盖了 sysctl。
第一件事是看宿主机当前值
sysctl vm.max_map_count临时提高并重新拉起容器
sysctl -w vm.max_map_count=262144 && docker restart es01接着写入持久配置避免重启失效
echo 'vm.max_map_count = 262144' > /etc/sysctl.d/99-es.conf && sysctl --system剩下的就是在容器里确认生效值
docker exec es01 cat /proc/sys/vm/max_map_count别只看报错消失，验证要多做一步。容器日志不再出现 max virtual memory areas 的报错，ES 进程稳定运行超过十分钟，集群健康状态从 red 恢复为 green。
这个参数只能从宿主机改，容器内的 sysctl 多半是只读的；调大之后也要关注 ES 自身的分片数，分片太多同样会撞上限。监控比日志更早给出信号，事后回看经常能提前半小时发现异常。