You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Elasticsearch version (bin/elasticsearch --version):
Version: 6.4.3, Build: default/tar/fe40335/2018-10-30T23:17:19.084789Z, JVM: 1.8.0_191
Plugins installed: []
none
JVM version (java -version):
openjdk version "1.8.0_191"
OpenJDK Runtime Environment (build 1.8.0_191-b12)
OpenJDK 64-Bit Server VM (build 25.191-b12, mixed mode)
OS version (uname -a if on a Unix-like system):
Linux c061993b6527 4.9.93-linuxkit-aufs #1 SMP Wed Jun 6 16:55:56 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
Description of the problem including expected versus actual behavior:
Currently, when Elasticsearch boots up and detects it is not just running on localhost, it will invoke the bootchecks mechanism to make sure various things are sanely configured. One of those checks is for the value of vm.max_map_count to be at least 262144.
The value of vm.max_map_count is only relevant when index.store.type=mmapfs; Consequently, When an Elasticsearch instance is configured to use another store type like niofs or simplefs, it should not check for the value of vm.max_map_count because the value is irrelevant to the niofs and simplefs storage types.
Steps to reproduce:
Run sysctl -w vm.max_map_count=10000
Set index.store.type: niofs in elasticsearch.yml
Set network.host: _site_ in elasticsearch.yml
Start Elasticsearch and observe log output
Watch ERROR message from bootchecks mechanism due to vm.max_map_count being to low despite the fact you're not using the mmapfs index store type.
Provide logs (if relevant):
The text was updated successfully, but these errors were encountered:
Based on your comments in #32421, I see you are about to check a nightly snapshot build of Elasticsearch 6.5.0 with node.store.allow_mmapfs set to false. We'll keep this issue open for now but that setting should likely help in your case.
I mananged to test with 6.5.0-SNAPSHOT and can confirm that the allow_mmapfs setting is picked up by Elasticsearch. Furthermore, when deploying in a non-standalone fashion, I can confirm that the bootcheck for vm.max_map_count is skipped and the masters come up.
Elasticsearch version (
bin/elasticsearch --version
):Version: 6.4.3, Build: default/tar/fe40335/2018-10-30T23:17:19.084789Z, JVM: 1.8.0_191
Plugins installed: []
none
JVM version (
java -version
):openjdk version "1.8.0_191"
OpenJDK Runtime Environment (build 1.8.0_191-b12)
OpenJDK 64-Bit Server VM (build 25.191-b12, mixed mode)
OS version (
uname -a
if on a Unix-like system):Linux c061993b6527 4.9.93-linuxkit-aufs #1 SMP Wed Jun 6 16:55:56 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux
Description of the problem including expected versus actual behavior:
Currently, when Elasticsearch boots up and detects it is not just running on localhost, it will invoke the bootchecks mechanism to make sure various things are sanely configured. One of those checks is for the value of
vm.max_map_count
to be at least262144
.By default, Elasticsearch sets
index.store.type
tofs
which means that Elasticsearch will select the performance-optimal index store type for the platform it's currently running on (see: https://www.elastic.co/guide/en/elasticsearch/reference/current/index-modules-store.html for details about the possible store types).The value of
vm.max_map_count
is only relevant when index.store.type=mmapfs; Consequently, When an Elasticsearch instance is configured to use another store type likeniofs
orsimplefs
, it should not check for the value ofvm.max_map_count
because the value is irrelevant to the niofs and simplefs storage types.Steps to reproduce:
sysctl -w vm.max_map_count=10000
index.store.type: niofs
inelasticsearch.yml
network.host: _site_
inelasticsearch.yml
mmapfs
index store type.Provide logs (if relevant):
The text was updated successfully, but these errors were encountered: