下面是我在RedHat/Centos 7上锁定ES节点上的内存所做的工作（如果其他发行版使用systemd，它将工作）。
您必须在4个不同的地方进行更改：
1)/etc/sysconfig/elasticsearch**
在sysconfig上：/etc/sysconfig/elasticsearch你应该有：

ES_JAVA_OPTS="-Xms4g -Xmx4g" 
MAX_LOCKED_MEMORY=unlimited

（将4g替换为建议的可用RAM的一半here）
2)/etc/security/limits.conf
在安全限制配置中：/etc/security/limits.conf你应该有

elasticsearch soft memlock unlimited
elasticsearch hard memlock unlimited

3)/usr/lib/systemd/system/elasticsearch.service
在服务脚本中：/usr/lib/systemd/system/elasticsearch.service你应该取消注解：

LimitMEMLOCK=infinity

在更改服务脚本后，应执行systemctl daemon-reload
4)/etc/elasticsearch/elasticsearch.yml
在elasticsearch配置中：/etc/elasticsearch/elasticsearch.yml您应该添加：

bootstrap.memory_lock: true

就是这样，重新启动节点，RAM将被锁定，你应该注意到一个重大的性能改进。

OS = Ubuntu 16
ElasticSearch = 5.6.3

我以前也有同样的问题。
我在elasticsearch.yml中设置

bootstrap.memory_lock: true

我在我的日志里写着：

elasticsearch进程请求内存锁定，但内存未锁定

我尝试了几件事，但实际上你只需要做一件事（根据https://www.elastic.co/guide/en/elasticsearch/reference/master/setting-system-settings.html）;
文件：

/etc/systemd/system/elasticsearch.service.d/override.conf

添加

[Service]
LimitMEMLOCK=infinity

稍微解释一下。
真正有趣的是，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完全忽略了它。

LimitMEMLOCK=65536

所以，我们得出结论。通过systemd启动elasticsearch
bootstrap.memory_lock：真的
我们不需要关心ulimit设置，但我们需要在systemd配置文件中明确设置它。
故事的结局

尝试在 /etc/sysconfig/elasticsearch 文件集中设置MAX_LOCKED_MEMORY=unlimited
在 /usr/lib/systemd/system/elasticsearch.service 中设置LimitMEMLOCK=infinity

确保 * 您的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开始（根据您的启动机制进行调整）。

检查进程运行时的实际限制（尽管很短）：

cat /proc/<pid>/limits

你会发现类似这样的行：

Limit                     Soft Limit           Hard Limit           Units     
Max cpu time              unlimited            unlimited            seconds   
Max file size             unlimited            unlimited            bytes     
Max data size             unlimited            unlimited            bytes     
Max stack size            8388608              unlimited            bytes     
Max core file size        0                    unlimited            bytes 
<truncated>

然后根据runner或container（在我的例子中是supervisord的minfds值），您可以解除实际的限制配置。
我希望它能为更一般的情况提供一点提示。

在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文件中。

如果你使用tar发行版 * 并且 * 想用monit来监视它，你必须告诉monit使用unlimited--这个配置的所有其他地方都被忽略了。
在/etc/init.d/monit的开头添加ulimit -s unlimited，然后执行systemctl daemon-reload，然后执行service monit restart和monit start $yourMonitLabel。

有一件事它“可以”是你的/tmp是挂载noexechttps://discuss.elastic.co/t/not-able-to-start-elasticsearch-due-to-failed-memory-lock/158009/6检查你的日志，看看它是否抱怨.UnsatisfiedLinkError：本机库，尤其是CentOS/RedHat，但也许其他？在ES 7中可以修复吗？

如果您在系统中激活了一个交换文件，那么ElasticSearch不能允许它分配的内存逃逸到磁盘-这将导致急剧放缓。所以它需要阻止内存被刷新到磁盘。为此，它进行一个特殊的系统调用，阻止将此内存刷新到磁盘。为了让ElasticSearch做到这一点，它需要提供一个环境变量：

boostrap.memory_lock=true

而且，为了让系统允许阻塞ElasticaSearch所需的内存，有必要允许运行ElasticaSearch的用户阻塞大量内存。为此，请在文件中写入：

/etc/security/limits.d/es.conf

内容：

elasticsearch soft memlock unlimited
elasticsearch hard memlock unlimited

如果你使用kubernetes来运行ElasticSearch，那么交换文件最初是禁用的，因此内存永远不会被刷新到磁盘。因此，ElasticSearch不需要锁定内存。因此，在Kubernetes中，您需要指定以下环境变量：

boostrap.memory_lock=false

你需要禁止ElasticSearch阻塞内存，因为这是不必要的，因为在kubernetes中没有swap-file。