Elasticsearch5进阶-设置(4)启动检查(Bootstrap Checks)
在Elasticsearch启动时,会对重要的配置进行检查,在不同的模式下,es会进行不同的提示:
- 开发模式下es将错误信息打印到日志中(warnning)
- 在生产环境下,es会直接启动报错,启动不了!
开发模式 vs. 生产模式
默认情况下,Elasticsearch是绑定到本机(network.host: 127.0.0.1),这样es可以进行正常的开发和使用!但是在生产环境下这样是不对的,因为需要外部地址进行发现和被发现从而形成集群!因此,如果Elasticsearch实例不将传输绑定到外部接口(默认),则将Elasticsearch实例置于开发模式,否则将其绑定到外部接口,否则处于生产模式。
请注意,HTTP可以通过http.host和transport.host独立于传输配置;这可以用于将单个实例配置为通过HTTP可访问以进行测试,而不会触发生产模式。
我们认识到一些用户需要将传输绑定到外部接口来测试它们对传输客户端的使用情况。对于这种情况,我们提供发现类型单节点( single-node
)(通过将discovery.type
设置为single-node
来配置);在这种情况下,节点将选择自己的主节点,并且不会与任何其他节点组成集群。
并且如果启用单节点,则可以避免启动检查(通过不绑定传输到外部接口,或将传输绑定到外部接口并将discovery.type
设置为single-node
)。对于这种情况,您可以通过将系统属性es.enforce.bootstrap.checks
设置为true
来强制执行启动检查(在设置JVM选项中设置此选项,或者通过将-Des.enforce.bootstrap.checks = true添加到环境中)变量ES_JAVA_OPTS)。如果您有这种需求,我们强烈建议您这样做。此系统属性可用于强制执行启动检查,而不依赖于节点配置。
堆检查(Heap size check)
如果JVM以不等的初始(Xms)和最大(Xmx)堆(heap)大小启动,则可能会在系统使用期间调整JVM堆的大小,因此可能会暂停。为了避免这些调整大小的停顿,最好使初始(Xms)堆(heap)大小等于最大Xms堆(heap)大小启动JVM。另外,如果启用了bootstrap.memory_lock,JVM将在启动时锁定堆(heap)的初始(Xms)大小。如果初始堆大小不等于最大堆大小,在重新调整大小之后,将不会将所有JVM堆锁定在内存中。要通过堆大小检查,必须配置堆大小。
此时我们来测试一下:
将config/jvm.options的xms修改为1g 默认2g ,
修改config/elasticsearch.yml中的network.host修改为0.0.0.0(绑定回环/局域网/外网)地址(---------------------------------- Network -----------------------------------下)
启动报错:
ERROR: [1] bootstrap checks failed
[1]: initial heap size [1073741824] not equal to maximum heap size [2147483648]; this can cause resize pauses and prevents mlockall from locking the entire heap
说明此时处于生产模式。
修改config/elasticsearch.yml(---------------------------------- Discovery-----------------------------------下) discovery.type为 single-node
discovery.type: single-node
再启动,启动成功!此时不进行启动检查!
File descriptor check 跳过
如有需要自行阅读:https://www.elastic.co/guide/en/elasticsearch/reference/current/_file_descriptor_check.html
注意:下面的所有内容尽量理解,不理解也别灰心,继续往下看,并且好多我目前没有能力理解的都没翻译
Memory lock check
当JVM执行主要的垃圾收集时,它会触及堆(Heap)的每一个页面。如果这些页面中的任何一个被替换到磁盘,那么它们将必须被交换回内存。这导致很多磁盘崩溃,Elasticsearch将更多地用于服务请求。有几种配置系统以禁止交换(swap)的方式。一种方法是通过请求JVM通过mlockall(Unix)或虚拟锁(Windows)将堆锁定在内存中。这通过Elasticsearch设置bootstrap.memory_lock完成。但是,有些情况下可以将此设置传递给Elasticsearch,但Elasticsearch无法锁定堆(例如,如果弹性搜索用户没有memlock无限制)。内存锁定检查验证是否启用了bootstrap.memory_lock设置,JVM能够成功地锁定堆。要通过内存锁检查,您可能需要配置mlockall。
最大线程数检查(Maximum number of threads check)
Elasticsearch通过将请求分解成阶段并将这些阶段移交给不同的线程池执行程序来执行请求。有不同的线程池执行器用于Elasticsearch中的各种任务。因此,Elasticsearch需要创建大量线程的能力。最大线程数检查确保Elasticsearch进程有权在正常使用下创建足够的线程。此检查仅在Linux上实施。如果您在Linux上,要传递最大数量的线程检查,您必须配置系统以允许Elasticsearch进程创建至少2048个线程。这可以通过使用nproc设置的/etc/security/limits.conf来完成(请注意,您可能还需要增加root用户的限制)。
最大虚拟内存检查(Maximum size virtual memory check)
Elasticsearch和Lucene使用mmap对索引的部分映射到Elasticsearch地址空间有很大的影响。这将保留某些索引数据不受JVM堆的影响,但会在内存中保持快速访问。为了使其有效,Elasticsearch应该具有无限的地址空间。最大大小的虚拟内存检查强制Elasticsearch进程具有无限的地址空间,仅在Linux上实施。要传递最大大小的虚拟内存检查,您必须配置系统以允许Elasticsearch进程具有无限的地址空间。这可以通过/etc/security/limits.conf使用as设置为unlimited来实现(请注意,您可能还需要增加root用户的限制)。
Maximum map count check
从前一点开始,为了有效地使用mmap,Elasticsearch还需要创建许多内存映射区域的能力。最大映射计数检查检查内核允许进程具有至少262,144个内存映射区域,并且仅在Linux上实施。要通过最大映射计数检查,您必须通过sysctl配置vm.max_map_count至少为262144。
Client JVM check
由OpenJDK派生的JVM提供两种不同的JVM:客户机JVM和服务器JVM。这些JVM使用不同的编译器从Java字节码生成可执行机器代码。客户端JVM针对启动时间和内存占用进行调整,同时调整服务器JVM以最大化性能。两个虚拟机之间的性能差异可能很大。客户端JVM检查确保Elasticsearch不在客户机JVM内运行。要通过客户端JVM检查,必须使用服务器VM启动Elasticsearch。在现代系统和操作系统上,服务器虚拟机是默认的。此外,Elasticsearch默认配置为强制服务器VM。
转载于:https://my.oschina.net/shibuyisha/blog/983723