Elasticsearch学习笔记(6)

目录

重要的系统配置

理想中,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"

如果你看到mlockallfalse,这意味着mlockall请求失败了。你还可以在日志中看到包含更多信息的一行,其中包含这些单词Unable to lock JVM Memory

在Linux/Unix系统上,最可能的原因的是运行Elasticsearch服务的用户没有权限去锁内存。这可以按照以下方式授予:

  • .zip and .tar.gz - 在启动Elasticsearch之前,使用root权限,设置ulimit -l unlimited,或者设置memlockunlimited在/etc/security/limits.conf.
  • RPM and Debian - 设置MAX_LOCKED_MEMORYunlimited在system configuration file (或者查看下面使用systemd的系统).
  • Systems using systemd - 设置LimitMEMLOCKinfinity在systemed configuration.

另一个可能的原因,为什么mlockall失败,是JNA临时目录(通常是/tmp的子目录)使用noexec选项挂载。这可以通过
为JNA指定一个新的临时目录,使用ES_JAVA_OPTS环境变量:

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

或者在jvm.options中配置文件中设置此JVM标志。

文件描述符

注意:这只适用于Linux和macOS,如果在Windows上运行Elasticsearch,可以忽略它。在Windows上,JVM只使用受可用资源限制的API。

Elasticsearch使用了很多文件描述符或者文件句柄。耗尽文件描述符可能是灾难性的,并且很可能导致数据丢失。确保将运行Elasticsearch的用户打开的文件描述符的数量限制增加到65,536或更高。

对于.zip.tar.gz包,使用root权限设置ulimit -n 65536在启动Elasticsearch之前,或者设置nofile65536在/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文件中设置nproc4096

包分发版在systemd下作为服务运行时将自动配置Elasticsearch进程的线程数。不需要额外的配置。

DNS cache settings

Elasticsearch运行时有一个安全管理器。有了安全管理器之后,JVM默认会无限期地缓存正面主机名解析。如果您的Elasticsearch节点在DNS解析随时间变化的环境中依赖于DNS(例如,用于节点到节点的发现),那么您可能需要修改默认的JVM行为。这可以通过增加networkaddress.cache.ttl=到你的Java安全策略修改。任何解析失败的主机都将被记录。还要注意,Java安全管理器就绪后,JVM默认将负主机名解析缓存10秒。这可以通过增加networkaddress.cache.negative.ttl=到你的java安全策略。

JNA临时目录不是使用noexec挂载

Elasticsearch使用JNA(Java Native Access)库来执行一些依赖于平台的本机代码。在Linux上,支持这个库的本地代码是在运行时从JNA存档中提取的。默认情况下,此代码被提取到Elasticsearch临时目录,该目录默认为/tmp的一个子目录。或者,可以使用JVM标志-Djna.tmpdir=控制这个位置。由于本机库作为可执行文件映射到JVM虚拟地址空间,提取此代码的位置的底层挂载点不能与noexec一起挂载,因为这会阻止JVM进程将此代码映射为可执行文件。在一些经过加固的Linux安装中,这是/tmp的默认挂载选项。使用noexec挂载底层挂载的一个迹象是,在启动时JNA将无法加载,随着一个java.lang.UnsatisfiedLinkerError异常,其消息与未能从共享对象映射段的行有关。注意,不同JVM版本之间的异常消息可能不同。此外,依赖于通过JNA执行本机代码的Elasticsearch组件将失败,消息表明这是因为JNA不可用。如果您看到这样的错误消息,则必须重新安装用于JNA的临时目录,以便不使用noexec挂载该目录。

下一章 —— Elasticsearch学习笔记(7)

你可能感兴趣的:(Elasticsearch学习笔记(6))