Elasticsearch：最大虚拟内存区域 vm.max_map_count [65530] 太低，增加到至少 [262144]答案

【问题标题】：Elasticsearch: Max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]Elasticsearch：最大虚拟内存区域 vm.max_map_count [65530] 太低，增加到至少 [262144]
【发布时间】：2018-12-28 23:03:42
【问题描述】：

我对 ElasticSearch 的 systemd 配置有疑问。

[Unit]
Description=platform-elasticsearch
After=syslog.target network.target remote-fs.target nss-lookup.target

[Service]
User={{ app_user }}
Group={{ app_group }}
Environment=ES_PATH_CONF=/platform/opt/elasticsearch-{{ elasticsearch.version }}/config
Environment=JAVA_HOME=/platform/opt/jdk{{ jdk.major_version }}_{{ jdk.minor_version }}
LimitAS=infinity
LimitRSS=infinity
LimitCORE=infinity
LimitNOFILE=100000
LimitMEMLOCK=100000
StandardOutput=syslog
StandardError=syslog
WorkingDirectory=/platform/var/app/elasticsearch
ExecStart=/platform/opt/elasticsearch-{{ elasticsearch.version }}/bin/elasticsearch
ExecReload=/bin/kill -s HUP $MAINPID
ExecStop=/bin/kill -s -TERM $MAINPID
TimeoutStopSec=60
# When a JVM receives a SIGTERM signal it exits with code 143
SuccessExitStatus=143 0
Type=simple
Restart=on-failure
RestartSec=10
PIDFile=/platform/var/run/elasticsearch.pid

[Install]
WantedBy=multi-user.target

这似乎不允许我配置 vm.max_map_count 设置。

Jul 20 14:53:46 scratchpad elasticsearch: [2018-07-20T14:53:46,359][INFO ][o.e.b.BootstrapChecks    ] [1oQJNUK] bound or publishing to a non-loopback     address, enforcing bootstrap checks
Jul 20 14:53:46 scratchpad elasticsearch: ERROR: [1] bootstrap checks failed
Jul 20 14:53:46 scratchpad elasticsearch: [1]: max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]
Jul 20 14:53:46 scratchpad elasticsearch: [2018-07-20T14:53:46,376][INFO ][o.e.n.Node               ] [1oQJNUK] stopping ...
Jul 20 14:53:46 scratchpad elasticsearch: [2018-07-20T14:53:46,414][INFO ][o.e.n.Node               ] [1oQJNUK] stopped
Jul 20 14:53:46 scratchpad elasticsearch: [2018-07-20T14:53:46,414][INFO ][o.e.n.Node               ] [1oQJNUK] closing ...
Jul 20 14:53:46 scratchpad elasticsearch: [2018-07-20T14:53:46,445][INFO ][o.e.n.Node               ] [1oQJNUK] closed
Jul 20 14:53:46 scratchpad systemd: platform-elasticsearch.service: main process exited, code=exited, status=78/n/a

具体问题如下：

Jul 20 14:53:46 scratchpad elasticsearch: [1]: max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]

我已经能够使用以下命令在命令行上启动弹性搜索：

sudo su -c 'echo 262144 > "/proc/sys/vm/max_map_count"' && \ 
export JAVA_HOME=/platform/opt/jdk1.8.0_181 && \
export ES_PATH_CONF=/platform/opt/elasticsearch-6.3.1/config && \
/platform/opt/elasticsearch-6.3.1/bin/elasticsearch

谁能告诉我为什么 LimitMEMLOCK=100000 不起作用，以及如何在 systemd 中有效地设置 max_map_count。

我也尝试过设置以下内容：

cat /etc/security/limits.d/30_elastic_limits.conf

vagrant       hard    nofile     500000
vagrant       hard    memlock     262144

但这似乎被 systemd 完全忽略了。

【问题讨论】：

标签： elasticsearch limit systemd cgroups

【解决方案1】：

Vivek's answer

sysctl -w vm.max_map_count=262144

是正确的，但是，该设置只会在会话期间持续。如果主机重新启动，设置将重置为原始值。

如果要永久设置，需要编辑/etc/sysctl.conf，将vm.max_map_count设置为262144。

当主机重新启动时，您可以通过运行sysctl vm.max_map_count 来验证设置是否仍然正确

【讨论】：

不要忘记重启或者：sysctl --system
非常感谢。这很有帮助。
注意，如果你重启机器，配置就会消失，所以这个方法不是永久的。

【解决方案2】：

使用所需参数将新条目插入 /etc/sysctl.conf 文件：

vm.max_map_count = 262144

它使更改永久化。

同时运行：

sysctl -w vm.max_map_count=262144

改变内核的当前状态。

如果你使用docker生效你应该重启它：

systemctl restart docker

【讨论】：

如果你不是root用户，你应该确保你有sudo权限并在执行上述操作之前使用sudo。
如果你使用docker-compose在宿主机上运行容器，你也可以用root权限运行这个命令sysctl -w vm.max_map_count=262144来解决这个问题。
使用sysctl vm.max_map_count=262144 (iwithout -w) 这样更改才可用，直到操作系统关闭。它是一个开发机器。所以，我不想永久改变。

【解决方案3】：

对于 windows 用户，使用 wsl 子系统

打开电源外壳运行

wsl -d docker-desktop

然后

sysctl -w vm.max_map_count=262144

【讨论】：

这适用于我在 Windows 10 机器上。最后一步是输入exit 以退出wsl。
工作得很好，非常感谢！可惜我不得不将命令复制到 power shell
这似乎不是 Docker Desktop 中的“粘性”变化——每次重启 Docker 时都必须运行该命令，这真的很讨厌。
谢谢！按预期工作

【解决方案4】：

请参阅Elasticsearch documentation about virtual memory。在 Centos 上，您可以使用以下命令：

sysctl -w vm.max_map_count=262144

【讨论】：

【解决方案5】：

这本身不是一个答案，而是从 docker 容器的角度对任何遇到操作问题的人的澄清/捷径。我在 docker 容器中运行的应用程序遇到了这个问题。正如here by nishant所解释的那样@

您不需要在容器级别为 Elasticsearch 增加虚拟内存，您可以通过运行以下命令为主机执行此操作：

sudo sysctl -w vm.max_map_count=262144

然后重新启动您的 docker-containers。

正如上面 val 所解释的那样，设置 max_map_count 这种方式不会在运行 docker 容器的机器重新启动时持续存在。所以你需要按照他上面解释的更持久的方式保存它。

【讨论】：

【解决方案6】：

您还可以通过使用single-node 发现类型来解决内存限制问题。在环境中设置这个：discovery.type=single-node

docker-compose.yml

services:
  es:
    image: elasticsearch
    environment:
      - discovery.type=single-node

另见：

https://github.com/docker/for-win/issues/5202#issuecomment-636028670

【讨论】：

【解决方案7】：

请运行以下命令：sysctl -w vm.max_map_count=262144 以增加 Elasticsearch 使用的默认虚拟内存。

注意：当您运行上述命令时，您的问题将得到解决，但这将是一个临时解决方案，因为节点/系统/容器重新启动，您的更改将会生效。所以如果你想永久设置这个，你需要编辑/etc/sysctl.conf并将vm.max_map_count设置为262144。

更多详情请点击here。

【讨论】：

【解决方案8】：

我在单节点弹性搜索集群中遇到了同样的问题。根据elastic-search documentation，对于运行单节点，您可以在 docker run 命令中使用 "discovery.type=single-node"。

docker run -p 9200:9200 -p 9300:9300 -e "discovery.type=single-node" docker.elastic.co/elasticsearch/elasticsearch:7.13.3

在 docker-compose.yml 中，你可以指定如下：

version: '3.1'
services:
 elastic_search:
  image: docker.elastic.co/elasticsearch/elasticsearch:7.13.3
  container_name: es01
  environment:
   - discovery.type=single-node
   - node.name=es01
   - bootstrap.memory_lock=true
   - "ES_JAVA_OPTS=-Xms512m -Xmx512m"
  ports:
   - 9200:9200
  networks:
   - elastic
networks:
 elastic:

【讨论】：

【解决方案9】：

最大虚拟内存区域 vm.max_map_count [65530] 太低，至少增加到 [262144]。
请运行以下命令来解决此问题：

sysctl -w vm.max_map_count=262144

【讨论】：

【解决方案10】：

vm.max_map_count=262144

将此行添加到下面的路径中

vim /etc/sysctl.conf

或转到此链接https://www.elastic.co/guide/en/elasticsearch/reference/current/vm-max-map-count.html

【讨论】：

除了现有答案之外，您的帖子还提供了哪些额外的见解？特别是与最受好评的答案和它所指的答案相比。尽量避免给人留下您通过使用同一问题的其他答案中的信息来创建答案的印象，尤其是当摘要已经存在时...
正如目前所写，您的答案尚不清楚。请edit 添加其他详细信息，以帮助其他人了解这如何解决所提出的问题。你可以找到更多关于如何写好答案的信息in the help center。