【Elasticsearch】 es ES节点memory lock重要性与实现方式

最新推荐文章于 2024-05-03 09:28:53 发布

九师兄

最新推荐文章于 2024-05-03 09:28:53 发布

阅读量1k

点赞数

分类专栏：大数据-Elasticsearch

原文链接：https://elasticsearch.cn/article/149

版权

大数据-Elasticsearch 专栏收录该内容

561 篇文章 549 订阅 ¥79.90 ¥99.00

订阅专栏

本文介绍了Elasticsearch中启用bootstrap.memory_lock的重要性，强调了防止交换以保障性能和节点稳定性。官方建议避免交换操作，因为它可能导致垃圾收集时间延长，使节点响应变慢或断开与集群的连接。通过检测、配置和重新启动ES节点，确保内存锁的正确设置，以优化Elasticsearch的运行状态。

摘要由CSDN通过智能技术生成

在这里插入图片描述

1.概述

转载：https://elasticsearch.cn/article/149

看一下Elastic官网对开启 bootstrap.memory_lock的介绍：

Swapping is very bad for performance and for node stability and should be avoided at all costs. It can cause garbage collections to last for minutes instead of milliseconds and can cause nodes to respond slowly or even to disconnect from the cluster. ----截取自官网

意思是说发生系统swapping的时候ES节点的性能会非常差，也会影响节点的稳定性。所以要不惜一切代价来避免swapping。swapping会导致Java GC的周期延迟从毫秒级恶化到分钟，更严重的是会引起节点响应延迟甚至脱离集群。

----如果不了解到底什么是swapping的，可以找点Linux IO章节文章看看

2.检测

先检查一下你的各个ES节点是否开启了Mem_lock


GET /_nodes?filter_path=**.mlockall

结果如下

{
  "nodes" : {
    "ZiR6PjzPSX6NI99Awisr2g" : {
      "process" : {
        "mlockall" : false
      }
    }
  }
}

上述返回内容，可见都没有开启mem_lock，集全随时都可能发生故障（尤其是集群正常运行了一段时间，莫名其妙的故障）

3.配置

root权限执行

 ulimit -l unlimited

告诉操作系统可以无限制分配内存给一个进程

4.重新启动ES

[2017-04-06T11:51:14,840][INFO ][o.e.b.BootstrapCheck     ] [Portal_ES_Node10_0_36_49] bound or publishing to a non-loopback or non-link-local address, enforcing bootstrap checks
ERROR: bootstrap checks failed
memory locking requested for elasticsearch process but memory is not locked

如果你遇到上面的错误，说明你还需要配置/etc/security/limits.conf
增加下面3行到文件末尾，其中XXX表示当前用户

# allow user 'XXX' mlockall
XXX soft memlock unlimited
XXX hard memlock unlimited