Elasticsearch中文文档3.4.2. 禁止交换
大多数操作系统尝试为文件系统的缓存使用尽可能多的内存，并尽早换出未使用的应用程序内存。这可能导致 JVM 堆的一部分甚至其可执行页面换出到磁盘上。
交换对于性能，节点稳定性非常不利，应不惜一切代价避免交换。它可能导致垃圾回收持续分钟而不是毫秒，并且可能导致节点响应缓慢甚至断开与群集的连接。在弹性分布式系统中，甚至让操作系统杀死该节点更为有效。
有三种禁用交换的方法。首选选项是完全禁用交换。如果这不是一个选择，那么在你的环境中要尽量减少交换性而不是内存锁定。
禁用所有交换文件
通常，Elasticsearch 是在机器上运行的唯一服务，其内存使用量由 JVM 选项控制，应无需启用交换功能。
在Linux系统上，您可以通过运行以下命令去临时禁用交换:
sudo swapoff -a不需要重启 Elasticsearch。
要永久禁用它，您将需要编辑 /etc/fstab 文件并注释包含 swap 单词的所有行。
在Windows上，可以通过以下方式完全实现此功能：系统属性 → 高级 → 性能 → 高级 → 虚拟内存。
配置 swappiness
在 Linux 系统上另一种可用的选择是确保将 sysctl值 vm.swappiness设置为1。这可以减少内核的交换趋势，并且在正常情况下不导致交换，同时仍然允许整个系统在紧急情况下进行交换。
启用 bootstrap.memory_lock
另一种选择是在 Linux / Unix 系统上使用 mlockall 或在 Windows 上使用 VirtualLock 尝试将进程地址空间锁定在 RAM 中，以防止任何 Elasticsearch 内存被换出。可以通过将以下行添加到 config / elasticsearch.yml 文件中来完成此操作：如果mlockall尝试分配的内存超过可用内存，则可能导致JVM或Shell会话退出！
启动 Elasticsearch 之后，您可以通过检查此请求的输出中的 mlockall 值来查看是否成功应用了此设置：
bootstrap.memory_lock: true如果 mlockall 尝试分配的内存超过可用内存，则可能导致 JVM 或 Shell 会话退出！
在启动 Elasticsearch 之后，您可以通过检查此请求的输出中的 mlockall 值来查看是否成功应用了此设置：
GET _nodes?filter_path=**.mlockall如果看到 mlockall 为 false ，则表示 mlockall 请求已失败。您还将在日志中看到一行包含更多信息的行，内容为“无法锁定 JVM 内存”。
在 Linux / Unix 系统上，最可能的原因是运行 Elasticsearch 的用户无权锁定内存。可以授予以下权限：
.zip和.tar.gz- 在启动 Elasticsearch 之前将
ulimit -l unlimited设置为 root 或者在/etc/security/limits.conf中将memlock设置为unlimited
- 在启动 Elasticsearch 之前将
- RPM 和 Debian
- 在系统配置文件中将
MAX_LOCKED_MEMORY设置为无限制(对于使用systemd 的系统，请参见下文)。
- 在系统配置文件中将
- 系统使用 systemd
- 在 systemd 配置中将
LimitMEMLOCK设置为无穷大
- 在 systemd 配置中将
mlockall 失败的另一个可能原因是 JNA 临时目录(通常是/ tmp的子.... 这可以通过使用ES_JAVA_OPTS环境变量为 JNA 指定新的临时目录来解决：
export ES_JAVA_OPTS="$ES_JAVA_OPTS -Djna.tmpdir=<path>"
./bin/elasticsearch或在 jvm.options 配置文件中设置此 JVM 标志。
本译文仅用于学习和交流目的，转载请务必注明文章译者、出处、和本文链接
我们的翻译工作遵照 CC 协议，如果我们的工作有侵犯到您的权益，请及时联系我们。
关于 LearnKu
粤公网安备 44030502004330号