我已经设置bootstrap.memory_lock=true更新/etc/security/limits.conf为ElasticSearch用户添加了memlock unlimited
我的ElasticSearch运行了好几个月。一天前突然失败了。在日志中,我可以看到下面的错误和进程从未启动
错误: Bootstrap 检查失败为elasticsearch进程请求的内存锁定,但内存未锁定
我点击ulimit -as,我可以看到最大锁定内存设置为无限。这里出了什么问题?我试了几个小时,但都是徒劳。请帮帮我
操作系统为RHEL 7.2 Elasticsearch 5.1.2
ulimit -作为输出
core file size (blocks -c) 0
data seg size (kbytes -d) unlimited
scheduling policy (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 83552
max locked memory (kbytes, -l) unlimited
max memory size (kbytes, -m) unlimited
open files (-n) 65536
pipe size (512 bytes, -q) 8
POSIX message queues (bytes,-q) 819200
real-time priority (-r) 0
stack size kbytes, -s) 8192
cpu time seconds, -t) unlimited
max user processes (-u) 4096
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
9条答案
按热度按时间o3imoua41#
下面是我在RedHat/Centos 7上锁定ES节点上的内存所做的工作(如果其他发行版使用systemd,它将工作)。
您必须在4个不同的地方进行更改:
1)/etc/sysconfig/elasticsearch**
在sysconfig上:
/etc/sysconfig/elasticsearch
你应该有:(将4g替换为建议的可用RAM的一半here)
2)/etc/security/limits.conf
在安全限制配置中:
/etc/security/limits.conf
你应该有3)/usr/lib/systemd/system/elasticsearch.service
在服务脚本中:
/usr/lib/systemd/system/elasticsearch.service
你应该取消注解:在更改服务脚本后,应执行
systemctl daemon-reload
4)/etc/elasticsearch/elasticsearch.yml
在elasticsearch配置中:
/etc/elasticsearch/elasticsearch.yml
您应该添加:就是这样,重新启动节点,RAM将被锁定,你应该注意到一个重大的性能改进。
yfjy0ee72#
我以前也有同样的问题。
我在elasticsearch.yml中设置
我在我的日志里写着:
elasticsearch进程请求内存锁定,但内存未锁定
我尝试了几件事,但实际上你只需要做一件事(根据https://www.elastic.co/guide/en/elasticsearch/reference/master/setting-system-settings.html);
文件:
添加
稍微解释一下。
真正有趣的是,systemd根本不真正关心ulimit设置。(https://fredrikaverpil.github.io/2016/04/27/systemd-and-resource-limits/)。你可以很容易地检查这个事实。
1.在/etc/security/limits.conf中设置
elasticsearch - memlock unlimited
1.检查elasticsearch的最大锁定内存是否无限制
$ sudo su elasticsearch -s /bin/bash $ ulimit -l
1.禁用 Bootstrap 。memory_lock:在/etc/elasticsearch/elasticsearch.yml中为true
# bootstrap.memory_lock:真实
1.通过systemd启动服务elasticsearch
# service elasticsearch start
1.检查什么最大内存锁定设置有服务elasticsearch后,它是启动
# systemctl show elasticsearch| grep -i limitmemlock
OMG!尽管我们通过ulimit设置了无限的最大内存锁大小,systemd完全忽略了它。
所以,我们得出结论。通过systemd启动elasticsearch
bootstrap.memory_lock:真的
我们不需要关心ulimit设置,但我们需要在systemd配置文件中明确设置它。
故事的结局
xj3cbfub3#
尝试在 /etc/sysconfig/elasticsearch 文件集中设置MAX_LOCKED_MEMORY=unlimited
在 /usr/lib/systemd/system/elasticsearch.service 中设置LimitMEMLOCK=infinity
rqenqsqc4#
确保 * 您的elasticsearch启动进程 * 配置为
unlimited
。对于如果例如你启动elasticsarch与另一个用户作为一个配置在/etc/security/limits.conf
或作为root
,而定义一个通配符条目在limits.conf(这是 * 不是 * 根)它不会工作。测试它以确保:你可以例如将
ulimit -a ; exit
放在/etc/init.d/elasticsearch
中的“#Start Daemon”之后,并以bash /etc/init.d/elasticsearch start
开始(根据您的启动机制进行调整)。tkclm6bt5#
检查进程运行时的实际限制(尽管很短):
你会发现类似这样的行:
然后根据runner或container(在我的例子中是supervisord的minfds值),您可以解除实际的限制配置。
我希望它能为更一般的情况提供一点提示。
ma8fv8wu6#
在ubuntu 18.04上使用elasticsearch 6.x,在文件
/usr/lib/systemd/system/elasticsearch.service
中没有条目LimitMEMLOCK=infinity
。因此,将其添加到该文件中并在
/etc/default/elasticsearch
中设置MAX_LOCKED_MEMORY=unlimited
就可以了。jvm选项可以添加到
/etc/elasticsearch/jvm.options
文件中。jslywgbw7#
如果你使用
tar
发行版 * 并且 * 想用monit
来监视它,你必须告诉monit
使用unlimited
--这个配置的所有其他地方都被忽略了。在
/etc/init.d/monit
的开头添加ulimit -s unlimited
,然后执行systemctl daemon-reload
,然后执行service monit restart
和monit start $yourMonitLabel
。jbose2ul8#
有一件事它“可以”是你的/tmp是挂载
noexec
https://discuss.elastic.co/t/not-able-to-start-elasticsearch-due-to-failed-memory-lock/158009/6检查你的日志,看看它是否抱怨.UnsatisfiedLinkError:本机库,尤其是CentOS/RedHat,但也许其他?在ES 7中可以修复吗?7rfyedvj9#
如果您在系统中激活了一个交换文件,那么ElasticSearch不能允许它分配的内存逃逸到磁盘-这将导致急剧放缓。所以它需要阻止内存被刷新到磁盘。为此,它进行一个特殊的系统调用,阻止将此内存刷新到磁盘。为了让ElasticSearch做到这一点,它需要提供一个环境变量:
而且,为了让系统允许阻塞ElasticaSearch所需的内存,有必要允许运行ElasticaSearch的用户阻塞大量内存。为此,请在文件中写入:
内容:
如果你使用kubernetes来运行ElasticSearch,那么交换文件最初是禁用的,因此内存永远不会被刷新到磁盘。因此,ElasticSearch不需要锁定内存。因此,在Kubernetes中,您需要指定以下环境变量:
你需要禁止ElasticSearch阻塞内存,因为这是不必要的,因为在kubernetes中没有swap-file。