目录
重要的系统配置
理想中，Elasticsearch应该单独在服务器上运行，并使用所有可用的资源。为了做到这一点，您需要配置您的操作系统，以允许运行Elasticsearch的用户访问比默认情况下允许的更多的资源。
在迁移到生产环境之前下面的设置必须考虑：
- 禁用交换区
- 增加文件描述符
- 确保足够的虚拟内存
- 确保足够的线程
- JVM DNS缓存设置
- 没有使用noexec挂载的临时目录
开发环境VS生产环境
默认情况下，Elasticsearch假定您在开发模式下工作。如果没有正确配置上述任何设置，将向日志文件写入警告，但是您将能够启动并运行Elasticsearch节点。
只要您配置了网络设置，比如network.host，Elasticsearch假设您正在转向生产环境，并将上述警告升级为异常。这些异常将阻止您的Elasticsearch节点启动。这是一个重要的安全措施，确保您不会因为服务器配置错误而丢失数据。
配置系统设置
在哪里配置系统设置取决于您已经使用了哪个包来安装Elasticsearch，以及您正在使用哪个操作系统。
当你使用.zip或者.tar.gz包时。系统设置可以如下配置：
- 临时性使用ulimit，或者
- 在/etc/security/limits.conf永久化
当使用RPM或者Debian包时，大多数系统设置在system configuration file。但是，使用systemd的系统需要在systemd configuration file中指定系统限制。
ulimit
在Linux系统上，ulimit可以用于临时更改资源限制。在切换到将运行Elasticsearch的用户之前，通常需要用root权限设置限制。例如， 要将打开的文件句柄数量(ulimit -n)设置为65,536，可以执行以下操作:
sudo su
ulimit -n 65536
su elasticsearch
- 切换为root用户
- 改变打开的文件句柄数
- 切换为elasticsearch用户以运行ELasticsearch
新限制只适用于当前会话。
您可以使用ulimit -a查询当前应用的所有限制。
/etc/security/limits.conf
在Linux系统上，可以通过编辑/etc/security/limits.conf来为特定用户设置持久的限制。要将elasticsearch用户打开的文件的最大数量设置为65,536，请将以下行添加到limits.conf文件:
elasticsearch - nofile 65536
此更改只会在下一次elasticsearch用户打开新会话时生效。
注意：对于由init.d启动的进程，Ubuntu忽略limits.conf文件。要启用limits.conf文件，编辑/etc/pam.d/su并取消以下行注释：
session required pam_limits.so
系统配置文件
在使用RPM或Debian包时，可以在系统配置文件中指定系统设置和环境变量，位于：
- RPM /etc/sysconfig/elasticsearch
- Debian /etc/default/elasticsearch
但是，对于使用systemd的系统，需要通过systemd指定系统限制。
Systemd configuration
在使用systemd的系统上使用RPM或Debian包时，必须通过systemd指定系统限制。
systemd服务文件(/usr/lib/systemd/system/elasticsearch.service)包含默认应用的限制。
要覆盖它们，添加一个名为/etc/systemd/system/elasticsearch.service.d/override.conf的文件(或者，您可以运行sudo systemctl edit elasticsearch，它会在默认编辑器中自动打开文件)。设置此文件中的任何更改，例如:
[Service]
LimitMEMLOCK = infinity
完成后，运行以下命令重新加载单元：
sudo systemctl daemon-reload
禁用交换区
大多数操作系统试图为文件系统缓存使用尽可能多的内存，并急切地交换未使用的应用程序内存。这可能导致JVM堆的某些部分，甚至其可执行页面被交换到磁盘。
交换对性能和节点稳定性非常不利，应该不惜一切代价避免。它可能导致垃圾收集持续几分钟而不是几毫秒，还可能导致节点响应缓慢，甚至与集群断开连接。在弹性分布式系统中，这会让操作系统更容易杀死节点。
有三种方法可以禁用交换。首选选项是完全禁用交换。如果这不是一个选项，那么是选择最小化交换区间还是选择内存锁定取决于您的环境。
禁用所有的交换文件
通常情况下，ELasticsearch是运行在服务器上的唯一服务，并且它的内存使用由JVM选项控制。不需要启用交换区间。
在Linux系统上，可以通过运行以下命令，暂时禁用交换：
sudo swapoff -a
要永久禁用它，需要编辑/etc/fstab文件并注释掉包含单词swap的任何行。
在Windows系统上，可以通过完全禁用分页文件来实现相同的功能：
计算机属性 -> 高级 -> 性能 -> 设置 -> 高级 -> 虚拟内存 -> 更改。
配置swappiness
Linux系统上可用的另一个选项是确保vm.swappiness的值设置为1。这减少了内核交换的倾向，在正常情况下不应该导致交换，同时仍然允许整个系统在紧急情况下交换。
Enable bootstrap.memory_lock
另一种选择是在Linux/Unix系统上使用mlockall，或者在Windows上使用VirtualLock，试图将进程地址空间锁定到RAM中，防止任何弹性搜索内存被交换出去。这可以通过在config/elasticsearch.yml文件中增加这一行：
bootstrap.memory_lock: true
警告：如果JVM或shell会话试图分配比可用内存更多的内存，mlockall可能会导致该会话退出。
在启动Elasticsearch之后，您可以通过以下这个请求的输出来检查mlockall的值来查看是否成功应用了该设置：
curl -X GET "localhost:9200/_nodes?filter_path=**.mlockall"
如果你看到mlockall是false，这意味着mlockall请求失败了。你还可以在日志中看到包含更多信息的一行，其中包含这些单词Unable to lock JVM Memory。
在Linux/Unix系统上，最可能的原因的是运行Elasticsearch服务的用户没有权限去锁内存。这可以按照以下方式授予：
- .zip and .tar.gz - 在启动Elasticsearch之前，使用root权限，设置ulimit -l unlimited，或者设置memlock为unlimited在/etc/security/limits.conf.
- RPM and Debian - 设置MAX_LOCKED_MEMORY为unlimited在system configuration file (或者查看下面使用systemd的系统).
- Systems using systemd - 设置LimitMEMLOCK为infinity在systemed configuration.
另一个可能的原因，为什么mlockall失败，是JNA临时目录(通常是/tmp的子目录)使用noexec选项挂载。这可以通过
为JNA指定一个新的临时目录，使用ES_JAVA_OPTS环境变量：
export ES_JAVA_OPTS="$ES_JAVA_OPTS -Djna.tmpdir=<path>"
./bin/elasticsearch
或者在jvm.options中配置文件中设置此JVM标志。
文件描述符
注意：这只适用于Linux和macOS，如果在Windows上运行Elasticsearch，可以忽略它。在Windows上，JVM只使用受可用资源限制的API。
Elasticsearch使用了很多文件描述符或者文件句柄。耗尽文件描述符可能是灾难性的，并且很可能导致数据丢失。确保将运行Elasticsearch的用户打开的文件描述符的数量限制增加到65,536或更高。
对于.zip和.tar.gz包，使用root权限设置ulimit -n 65536在启动Elasticsearch之前，或者设置nofile为65536在/etc/security/limits.conf。
在macOS上，您还必须将JVM选项-XX:-MaxFDLimit传递给Elasticsearch，以便使用更高的文件描述符限制。
RPM和Debian包已经将文件描述符的最大数量默认为65536，不需要进一步配置。
可以使用Nodes StatsAPI检查每个节点配置的max_file_descriptors:
curl -X GET "localhost:9200/_nodes/stats/process?filter_path=**.max_file_descriptors"
响应格式：
{
"nodes": {
"DWaSfWz_TpGL-SvtDFeAgA": {
"process": {
"max_file_descriptors": 65536
}
}
}
}
虚拟内存
Elasticsearch默认使用mmapfs目录存储索引。操作系统默认限制的mmap数可能太低，这可能导致内存不足异常。
在Linux系统上， 你可以使用root权限增加限制数通过运行以下命令：
sysctl -w vm.max_map_count=262144
要永久设置该值，在/etc/sysctl.conf文件中更新vm.max_map_count设置。重启后运行sysctl vm.max_map_count验证。
RPM和Debian包将自动配置此设置。无需进一步配置。
线程数
Elasticsearch为不同类型的操作使用许多线程池。重要的是，它能够在需要时创建新线程。确保Elasticsearch用户可以创建的线程数至少为4096。
这可以在启动Elasticsearch之前使用root权限设置ulimit -u 4096，或者通过在/etc/security/limits.conf文件中设置nproc为4096。
包分发版在systemd下作为服务运行时将自动配置Elasticsearch进程的线程数。不需要额外的配置。
DNS cache settings
Elasticsearch运行时有一个安全管理器。有了安全管理器之后，JVM默认会无限期地缓存正面主机名解析。如果您的Elasticsearch节点在DNS解析随时间变化的环境中依赖于DNS(例如，用于节点到节点的发现)，那么您可能需要修改默认的JVM行为。这可以通过增加networkaddress.cache.ttl=<timeout>到你的Java安全策略修改。任何解析失败的主机都将被记录。还要注意，Java安全管理器就绪后，JVM默认将负主机名解析缓存10秒。这可以通过增加networkaddress.cache.negative.ttl=<timeout>到你的java安全策略。
JNA临时目录不是使用noexec挂载
Elasticsearch使用JNA(Java Native Access)库来执行一些依赖于平台的本机代码。在Linux上，支持这个库的本地代码是在运行时从JNA存档中提取的。默认情况下，此代码被提取到Elasticsearch临时目录，该目录默认为/tmp的一个子目录。或者，可以使用JVM标志-Djna.tmpdir=<path>控制这个位置。由于本机库作为可执行文件映射到JVM虚拟地址空间，提取此代码的位置的底层挂载点不能与noexec一起挂载，因为这会阻止JVM进程将此代码映射为可执行文件。在一些经过加固的Linux安装中，这是/tmp的默认挂载选项。使用noexec挂载底层挂载的一个迹象是，在启动时JNA将无法加载，随着一个java.lang.UnsatisfiedLinkerError异常，其消息与未能从共享对象映射段的行有关。注意，不同JVM版本之间的异常消息可能不同。此外，依赖于通过JNA执行本机代码的Elasticsearch组件将失败，消息表明这是因为JNA不可用。如果您看到这样的错误消息，则必须重新安装用于JNA的临时目录，以便不使用noexec挂载该目录。
