Elasticsearch : Les zones de mémoire virtuelle maximale vm.max_map_count [65530] est trop faible, augmenter à au moins [262144].

Question

J'ai un problème avec une configuration systemd pour ElasticSearch.

[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

Cela ne semble pas me permettre de configurer le paramètre 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

Le problème spécifique est le suivant :

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]

J'ai pu lancer une recherche élastique en ligne de commande avec la commande suivante :

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 

Quelqu'un peut-il me dire pourquoi LimitMEMLOCK=100000 ne fonctionne pas, et comment je peux effectivement définir max_map_count à partir de systemd.

J'ai également essayé de définir les éléments suivants :

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

vagrant       hard    nofile     500000
vagrant       hard    memlock     262144

mais cela semble être totalement ignoré par systemd.

Answer 1

La réponse de Vivek

sysctl -w vm.max_map_count=262144

est correct, mais le paramètre ne durera que le temps de la session. Si l'hôte redémarre, le paramètre sera réinitialisé à sa valeur initiale.

Si vous voulez définir ce paramètre de manière permanente, vous devez modifier /etc/sysctl.conf et mettre vm.max_map_count au 262144.

Quand l'hôte redémarre, vous pouvez vérifier que le paramètre est toujours correct en exécutant sysctl vm.max_map_count

Answer 2

Insérez la nouvelle entrée dans le fichier /etc/sysctl.conf avec le paramètre requis :

vm.max_map_count = 262144

il rend les changements permanents.

Courir aussi :

sysctl -w vm.max_map_count=262144

modifier l'état actuel du noyau.

Si vous utilisez docker pour prendre effet, vous devez le redémarrer :

systemctl restart docker

Answer 3

Voir le Documentation d'Elasticsearch sur la mémoire virtuelle . Sur Centos, vous pouvez le faire avec la commande suivante :

sysctl -w vm.max_map_count=262144

Answer 4

Il ne s'agit pas d'une réponse en soi, mais d'une clarification ou d'un raccourci pour quiconque rencontre le même problème que l'opérateur du point de vue des conteneurs Docker. J'ai eu ce problème à partir d'une application fonctionnant dans un conteneur docker. Et comme expliqué ici par nishant

Vous n'avez pas besoin d'augmenter la mémoire virtuelle pour Elasticsearch au niveau du conteneur, vous pouvez le faire pour la machine hôte en exécutant cette commande :

sudo sysctl -w vm.max_map_count=262144

et ensuite redémarrez vos conteneurs docker.

Comme expliqué par val ci-dessus, cette max_map_count de cette manière ne sera pas persistante au redémarrage de la machine sur laquelle tourne le conteneur docker. et donc vous devrez l'enregistrer d'une manière plus persistante comme il l'a expliqué ci-dessus.

Answer 5

Veuillez exécuter la commande suivante : sysctl -w vm.max_map_count=262144 pour augmenter la mémoire virtuelle par défaut utilisée par Elasticsearch.

Nota: Lorsque vous exécutez la commande mentionnée ci-dessus, votre problème sera résolu, mais il s'agit d'une solution temporaire, car le nœud/système/conteneur sera redémarré et vos modifications disparaîtront. Donc si vous voulez définir ceci de façon permanente, vous devez éditer /etc/sysctl.conf et mettre vm.max_map_count à 262144 .

Pour plus de détails, cliquez sur aquí .