elasticsearch7——引导检查
一、Maximum size virtual memory check失败
通过dockercompose运行elaticsearch时，报错误信息：
max virtual memory areas vm.max_map_count [65530] is too low, increase to at least [262144]复制代码
这个错误是由于最大虚拟内存区域 vm.max_map_count [65530] 太小，需要增加到至少 [262144]。
解决方法
使elaticsearch运行在开发模式，设置回环网络
network.host: 0.0.0.0linux可执行
sudo sysctl -w vm.max_map_count=262144临时解决这个问题；在window中，通过wsl运行的linux系统修改参数解决该错误，但是
docker重启失效。
sysctl -w vm.max_map_count=262144复制代码
通过win10 的wsl修改参数，重启后依旧生效
C:\Users\86178>wsl -d docker-desktop LAPTOP-KFPIFLPS:/tmp/docker-desktop-root/mnt/host/c/Users/86178# /proc/sys/vm/max_map_count复制代码
二、引导检查
这个错误是在elasticsearch启动阶段触发的，查询相关文档才知道这是启动阶段的引导检查机制。以前在学习ES的时候还没有这个机制或者忽略了该机制。引导检查机制是利器也是束缚，它通过严格的启动检查保证了ES能顺利运行。
在软件启动前期，elasticsearch会进行引导检查。在以前版本的 Elasticsearch 中，其中一些重要设置的错误配置会被记录为警告，因此用户有时会错过这些日志消息。为了确保这些设置得到应有的关注，Elasticsearch 在启动时进行了引导检查。
这些引导程序检查会检查各种 Elasticsearch 和系统设置，并将它们与对 Elasticsearch 的操作安全的值进行比较。
当Elasticsearch 处于
开发模式时，则任何失败的引导程序检查都会添加提示到 Elasticsearch的warn 日志；当Elasticsearch 处于
生产模式时，任何失败的引导程序检查都会导致 Elasticsearch拒绝启动。
如果一个 Elasticsearch 节点不能通过非环回地址与另一台机器形成集群，我们认为它处于开发模式；如果它可以通过非环回地址加入集群，则认为它处于生产模式。常见的回环地址：127.0.0.1
相关的引导检查如下：
Heap size check
File descriptor check
Memory lock check
Maximum number of threads check
Max file size check
Maximum size virtual memory check
Maximum map count check
Client JVM check
Use serial collector check
System call filter check
OnError and OnOutOfMemoryError checks
Early-access check
G1GC check
All permission check
Discovery configuration check
内存相关
Heap size check
Heap size check表示的是检查堆大小。在默认情况下，Elasticsearch 会根据节点的角色和总内存自动调整 JVM 堆的大小 。如果您手动覆盖默认大小并以不同的初始和最大堆大小启动 JVM，则 JVM 可能会在系统使用期间调整堆大小时暂停。如果启用 bootstrap.memory_lock，JVM 会在启动时锁定初始堆大小。如果初始堆大小不等于最大堆大小，则某些 JVM 堆在调整大小后可能不会被锁定。
Memory lock check
Memory lock check表示检查内存锁。当 JVM 进行垃圾收集时，会触及堆相关的所有页。但是，这些页可能会被换出磁盘。这时，可以通过mlockall（Unix）或虚拟锁（Windows）请求JVM将堆锁定在内存中，这可以设置bootstrap.memory_lock: true禁止页面交换。
这仅与 Linux 和 macOS 相关，如果在 Windows 上运行 Elasticsearch，则可以安全地忽略它。在 Windows 上，JVM 使用 仅受可用资源限制的API。
mlockall如果尝试分配的内存多于可用内存，则可能会导致 JVM 或 shell 会话退出！
在 Linux/Unix 系统上，运行 Elasticsearch 的用户需要授予锁定内存的权限。
设置ulimit
sudo su ulimit -n 65535 su elasticsearch 复制代码
或者设置memlock为unlimited
vim /etc/security/limits.conf elasticsearch soft memlock unlimited elasticsearch hard memlock unlimited复制代码
Maximum size virtual memory check
Maximum size virtual memory check表示强制检查最大虚拟内存的大小。
Elasticsearch 和 Lucene 使用mmap将索引的部分映射到 Elasticsearch 地址空间中；这会将某些索引数据保留在 JVM 堆之外，但保留在内存中以便快速访问。为了使其有效，Elasticsearch 应该有无限的地址空间。要通过该检查，必须配置系统使它允许 Elasticsearch 进程拥有无限地址空间的能力。
如果该检查失败，可以编辑/etc/security/limits.conf文件，添加<user> - as unlimited。
Maximum map count check
Maximum map count check表示检查最大映射计数，检查内核是否允许进程具有至少 262,144 个内存映射区域，并且仅在 Linux 上强制执行。
为了mmap有效地使用，Elasticsearch 还需要能够创建许多内存映射区域
sysctl -w vm.max_map_count=262144复制代码
仅当使用
mmapfs或hybridfs作为索引的存储类型时才需要Maximum map count check
线程相关
Maximum number of threads check
Maximum number of threads check表示检查最大线程数是否足够
Elasticsearch 通过将请求分解为多个阶段并将这些阶段交给不同的线程池执行程序来执行请求。对于 Elasticsearch 中的各种任务，有不同的线程池执行器。为了保证线程池里有足够的线程，需要在引导检查阶段检查可以分配的线程数。
此检查仅在 Linux 上强制执行。如果您在 Linux 上，要通过最大线程数检查，您必须配置您的系统以允许 Elasticsearch 进程能够创建至少 4096 个线程；这可以通过编辑/etc/security/limits.conf 设置nproc来完成。
文件相关
File descriptor check
File descriptor check表示检查文件描述符。文件描述符是一种用于跟踪打开文件的Unix 结构。“文件”可以是物理文件、虚拟文件（例如，/proc/loadavg）或网络套接字。Elasticsearch 使用了很多文件描述符或文件句柄，耗尽的文件描述符可能是灾难性的，并且很可能会导致数据丢失。确保将运行 Elasticsearch 的用户的打开文件描述符数量限制增加到 65,536 或更高。
Max file size check
Max file size check表示对最大文件的大小检查。ElaticSearch执行时对大文件分片后的segment文件和translog文件。在 Elasticsearch 进程可以创建的文件的最大大小受到限制的系统上，这可能会导致写入失败。
如果该检查失败，可以编辑/etc/security/limits.conf文件，设置fsize为unlimited。
JVM
Client JVM check
Client JVM check表示检查JVM客户端，确保 Elasticsearch 不在客户端 JVM 内运行。
OpenJDK 派生的 JVM 提供了两种不同的 JVM：
client JVM
server JVM
这些 JVM 使用不同的编译器从 Java 字节码生成可执行的机器代码；客户端 JVM 针对启动时间和内存占用进行了调整，而服务器 JVM 则针对最大化性能进行了调整。
Use serial collector check
Use serial collector check表示检测是否使用串行的垃圾收集。要通过串行收集器检查，不能使用串行收集器启动 Elasticsearch。
Elasticsearch 附带的默认 JVM 配置将 Elasticsearch 配置为在 JDK14 及更高版本中使用 G1GC 垃圾收集器。对于较早的 JDK 版本，配置默认为 CMS 收集器。
OnError and OnOutOfMemoryError checks
如果 JVM 遇到致命错误时，可以附带JVM 选项OnError和OnOutOfMemoryError到任意启动命令。使用该选项和系统调用过滤器是不兼容的，该检查会比较设置是否冲突。
Early-access check
Early-access check检查JVM版本是否是非正式版本，非正式版本无法启动。OpenJDK 项目提供了即将发布的版本的抢先体验快照。这些版本不适合生产。抢先体验检查检测这些抢先体验快照。要通过此检查，您必须在 JVM 的发布版本上启动 Elasticsearch。
G1GC check
G1GC check 会检测这些 HotSpot JVM 的早期版本。JDK 8 附带的早期版本的 HotSpot JVM 在启用 G1GC 收集器时可能会导致索引损坏,受影响的版本早于 JDK 8u40 附带的 HotSpot 版本。G1GC 检查。
系统相关
System call filter check
System call filter check表示检查系统调用过滤器是否存在，确保如果启用了系统调用过滤器，则相关过滤器已成功安装。要通过系统调用过滤器检查，您必须修复系统上阻止系统调用过滤器安装的任何配置错误。
用户可以设置bootstrap.system_call_filter=false关闭系统过滤器，跳过该检查。但是，需要自行承担相关风险。
All permission check
All permission check 检查确保引导期间使用的安全策略不会为Elasticsearch授予java.security.AllPermission权限；使用授予的所有权限运行相当于禁用安全管理器。
Discovery configuration check
默认情况下，当 Elasticsearch 首次启动时，它会尝试发现在同一主机上运行的其他节点。如果在几秒钟内无法发现任何选定的主节点，那么 Elasticsearch 将形成一个集群，其中包含已发现的任何其他节点。在开发模式下无需任何额外配置即可形成此集群很有用，但这不适用于生产，因为可能形成多个集群并因此丢失数据。
此引导程序检查可确保发现未使用默认配置运行。可以通过设置至少以下属性之一来满足它：
discovery.seed_hostsdiscovery.seed_providerscluster.initial_master_nodes
作者：此间码农
链接：https://juejin.cn/post/7031724420242620424