web-dev-qa-db-ja.com

エラスティック検索の最大仮想メモリ領域vm.max_map_count [65530]が低すぎるため、少なくとも[262144]に増加します

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によって完全に無視されるようです。

elasticsearchlimitsystemdcgroups
23
casibbald

Vivekの答え

sysctl -w vm.max_map_count=262144

ただし、設定はセッションの間だけ持続します。ホストが再起動すると、設定は元の値にリセットされます。

これを永続的に設定する場合は、/etc/sysctl.confを編集し、vm.max_map_countを262144に設定する必要があります。

ホストが再起動したら、sysctl vm.max_map_countを実行して設定がまだ正しいことを確認できます

34
Val

仮想メモリに関するElasticsearchドキュメント を参照してください。 Centosでは、次のコマンドで実行できます。

sysctl -w vm.max_map_count=262144
16
Vivek Pakmode

これはそれ自体の答えではなく、ドッカーコンテナの観点から操作の問題を抱えている人のための明確化/ショートカットです。 Dockerコンテナで実行されているアプリケーションでこの問題が発生しました。そして、説明したように ここではnishant

コンテナレベルでElasticsearchの仮想メモリを増やす必要はありません。次のコマンドを実行することで、ホストマシンに対してそれを行うことができます。

Sudo sysctl -w vm.max_map_count=262144

そして、ドッカーコンテナを再起動します。

上記のvalで説明したように、このmax_map_countをこのように設定すると、Dockerコンテナを実行しているマシンを再起動しても持続しません。そのため、上記で説明したように、より永続的な方法で保存する必要があります。

6
yonga springfield