重要的系统配置

配置系统设置的位置取决于您用于安装 Elasticsearch 的软件包，以及您使用的操作系统。

当使用.zip或.tar.gz包时，可以配置系统设置：

当使用RPM或Debian包时，大多数系统设置都在系统配置文件中设置。然而，使用systemd的系统要求在systemd配置文件中指定系统限制。

sudo su  
ulimit -n 65535 
su elasticsearch 

elasticsearch  -  nofile  65535

# session    required   pam_limits.so

[Service]
LimitMEMLOCK=infinity

sudo systemctl daemon-reload

大多数操作系统会尽可能多地使用内存用于文件系统缓存，并积极地将未使用的应用程序内存交换出去。这可能导致JVM堆的部分甚至其可执行页面被交换到磁盘上。

交换对性能和节点稳定性非常不利，应不惜一切代价避免。它可能导致垃圾收集持续几分钟而不是毫秒，并可能导致节点响应缓慢甚至从集群中断开连接。在一个具有弹性的分布式系统中，让操作系统杀死节点更为有效。

有三种方法可以禁用交换。首选选项是完全禁用交换。如果这不是一个选项，是否优先考虑最小化swappiness与内存锁定取决于您的环境。

sudo swapoff -a

bootstrap.memory_lock: true

GET _nodes?filter_path=**.mlockall

export ES_JAVA_OPTS="$ES_JAVA_OPTS -Djna.tmpdir=<path>"
./bin/elasticsearch

Elasticsearch 使用了大量的文件描述符或文件句柄。文件描述符耗尽可能会导致灾难性后果，并很可能导致数据丢失。请确保将运行 Elasticsearch 的用户打开文件描述符的数量限制增加到 65,535 或更高。

对于.zip和.tar.gz包，在启动Elasticsearch之前，以root身份设置ulimit -n 65535，或者在/etc/security/limits.conf中将nofile设置为65535。

在 macOS 上，您还必须将 JVM 选项 -XX:-MaxFDLimit 传递给 Elasticsearch，以便它能够利用更高的文件描述符限制。

RPM 和 Debian 包已经默认将文件描述符的最大数量设置为 65535，不需要进一步配置。

您可以使用Nodes stats API检查为每个节点配置的max_file_descriptors，方法如下：

GET _nodes/stats/process?filter_path=**.max_file_descriptors

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 进程的当前 mmap 计数，其中 $PID 是正在运行的 Elasticsearch 进程的进程 ID：

wc -l /proc/$PID/maps

Elasticsearch 使用多个线程池来处理不同类型的操作。 确保它能够在需要时创建新线程非常重要。请确保 Elasticsearch 用户可以创建的线程数至少为 4096。

这可以通过在启动Elasticsearch之前以root身份设置ulimit -u 4096来完成，或者通过在/etc/security/limits.conf中将nproc设置为4096来完成。

当作为服务在 systemd 下运行时，软件包分发将自动配置 Elasticsearch 进程的线程数。无需额外配置。

Elasticsearch 在启用安全管理器的情况下运行。启用安全管理器后，JVM 默认无限期缓存正向主机名解析，并默认缓存十秒的负向主机名解析。Elasticsearch 使用默认值覆盖此行为，以缓存六十秒的正向查找，并缓存十秒的负向查找。这些值应适用于大多数环境，包括 DNS 解析随时间变化的环境。如果不适用，您可以编辑 JVM 选项 中的 es.networkaddress.cache.ttl 和 es.networkaddress.cache.negative.ttl 值。请注意，networkaddress.cache.ttl= 和 networkaddress.cache.negative.ttl= 在 Java 安全策略 中被 Elasticsearch 忽略，除非您删除 es.networkaddress.cache.ttl 和 es.networkaddress.cache.negative.ttl 的设置。

Elasticsearch 使用 Java Native Access (JNA) 库，以及另一个名为 libffi 的库，用于执行一些平台相关的本地代码。在 Linux 上，支持这些库的本地代码在运行时被提取到一个临时目录中，然后映射到 Elasticsearch 地址空间中的可执行页。这要求底层文件不在以 noexec 选项挂载的文件系统上。

默认情况下，Elasticsearch 会在 /tmp 目录下创建其临时目录。然而，一些强化过的 Linux 安装默认会将 /tmp 挂载为 noexec 选项。这会阻止 JNA 和 libffi 正常工作。例如，在启动时，JNA 可能会因 java.lang.UnsatisfiedLinkerError 异常或类似 failed to map segment from shared object 的消息而无法加载，或者 libffi 可能会报告类似 failed to allocate closure 的消息。请注意，异常消息可能会因 JVM 版本而异。此外，依赖于通过 JNA 执行本地代码的 Elasticsearch 组件可能会因显示 because JNA is not available 的消息而失败。

要解决这些问题，请从您的 /tmp 文件系统中移除 noexec 选项，或者通过设置 $ES_TMPDIR 环境变量来配置 Elasticsearch 使用不同的临时目录位置。例如：

如果您需要更精细地控制这些临时文件的位置，您也可以使用 JVM 标志 -Djna.tmpdir= 配置 JNA 使用的路径，并且可以通过设置 LIBFFI_TMPDIR 环境变量来配置 libffi 使用的临时文件路径。未来的 Elasticsearch 版本可能需要额外的配置，因此您应尽可能设置 ES_TMPDIR。

每对 Elasticsearch 节点通过多个 TCP 连接进行通信，这些连接 保持打开，直到其中一个节点关闭或 节点之间的通信因底层基础设施的故障而中断。

TCP通过隐藏通信应用程序的临时网络中断，在偶尔不可靠的网络上提供可靠的通信。您的操作系统将在通知发送方任何问题之前，重新传输任何丢失的消息多次。Elasticsearch必须等待重新传输发生，并且只能在操作系统决定放弃时做出反应。因此，用户也必须等待一系列重新传输完成。

大多数Linux发行版默认重传任何丢失的数据包15次。重传以指数方式退避，因此这15次重传需要超过900秒才能完成。这意味着Linux需要很多分钟才能通过这种方法检测到网络分区或节点故障。Windows默认只重传5次，这对应于大约13秒的超时时间。

Linux 默认允许在可能经历非常长时间的数据包丢失的网络中进行通信，但这个默认设置在大多数 Elasticsearch 安装使用的高质量网络上是过度的，甚至是有害的。当集群检测到节点故障时，它会通过重新分配丢失的分片、重新路由搜索以及可能选举新的主节点来做出反应。高可用性集群必须能够及时检测节点故障，这可以通过减少允许的重传次数来实现。与远程集群的连接也应优先于 Linux 默认设置，更快地检测故障。因此，Linux 用户应减少 TCP 重传的最大次数。

您可以通过以root身份运行以下命令，将TCP重传的最大次数减少到5。五次重传对应的超时时间大约为13秒。

sysctl -w net.ipv4.tcp_retries2=5

要永久设置此值，请在 /etc/sysctl.conf 文件中更新 net.ipv4.tcp_retries2 设置。重启后验证，请运行 sysctl net.ipv4.tcp_retries2。