无法为 elasticsearch 更改 vm.max_map_count

Question

史前史

我在 CentOS 6.5 上运行 elasticsearch 和 SugarCRM7。我每天都面临同样的问题：java outOfMemory 错误。发生这种情况是因为 vm.max_map_count 值很小，只有在推荐 262144 时才 65530。

问题

问题是 vm.max_map_count 似乎无法改变：

1. 在根下更改

   sudo sysctl -w vm.max_map_count=262144
   

   返回

   错误：对键“vm.max_map_count”的权限被拒绝

   尽管

   ps aux | grep java
   

   仅返回 grep 进程

2. 在 elasticsearch 启动时更改

   sudo service elasticsearch start
   

   也返回错误

   错误：对键“vm.max_map_count”的权限被拒绝

   启动弹性搜索：[确定]

3. 通过文件手动更改（dirty-dirty hack）：

   sudo vi /proc/sys/vm/max_map_count
   

   也不起作用：

   "/proc/sys/vm/max_map_count" [只读]​​ 1L, 6C

   -- INSERT -- W10：警告：更改只读文件

   E45: 'readonly' 选项已设置（添加 ! 以覆盖）

   "/proc/sys/vm/max_map_count" E212: 无法打开文件进行写入

   尽管

   ls -la /proc/sys/vm/ | grep max_map_count
   

   退货

   -rw-r--r-- 1 根根 0 Apr 10 09:36 max_map_count

   （但我想这对于 linux 谈论 /proc 目录是正常的）

那么我怎样才能改变这个变量的值呢？每晚重新启动elasticsearch不是一个好主意......或者至少有人知道为什么会发生这个错误？

Answer 1

你快到了，无论是虚拟机还是物理机，这些设置总是可变的。

我将展示3种方法。

一些前置信息：

1) 如果可能，最好以 root 身份执行。

2) unix 上的/proc不是一个真正的文件系统，它是一个内存内核文件系统，但它看起来像一个普通的磁盘文件系统。您可以将其称为“假文件系统”或“特殊文件系统”，您不能使用 vi 或任何其他编辑器编辑这些假文件，因为它们不是文件，它们只是看起来像文件。几年前我遇到了同样的问题。

但是改变它们的值很简单，只需要另一种“机制”来编辑它们。

我将解释：首先，需要是 root ：（sudo 确实在某些发行版中有效，但在您尝试过的其他一些发行版中不起作用，第一种方法是通用的，适用于任何 Linux、macOS 或任何基于 Unix 的. 希望你能获得root密码。

按提示继续：

    $ su root

输入根密码。

现在你是 root，让我们检查当前值：/proc/sys/vm/max_map_count

    $ cat /proc/sys/vm/max_map_count  
    65536

让我们改变它：

    echo 262144 > /proc/sys/vm/max_map_count

我们来验证一下：

    cat /proc/sys/vm/max_map_count
    262144

完成！并且它已经被应用和发挥作用。通过更改 /proc 下任何伪文件的值，设置立即生效。但它们在重新启动后不会持续存在。您可以在elasticsearh或任何其他应用程序或系统指标上使用值并衡量性能变化。去调整你的系统，把值写在纸上，保持最好的值。如有任何错误，重新启动，它们将全部恢复到原始值，并重新开始，直到所有希望的值都是最佳的。/proc 下有很多磁盘和内存可调参数。如果您对它们进行良好的调整（并且有时间进行调整），它们会产生巨大的差异并提高性能。你走对了。

满意后，让我们将它们永久化：

第一种方法：

使用/etc/rc.local

    vi /etc/rc.local 

将所有参数放在 rc.local 文件中，例如：

    echo 220000000 > /proc/sys/vm/dirty_background_bytes
    echo 320000000 > /proc/sys/vm/dirty_bytes
    echo 0 > /proc/sys/vm/dirty_background_ratio
    echo 0 > /proc/sys/vm/dirty_ratio
    echo 500 > /proc/sys/vm/dirty_writeback_centisecs
    echo 4500 > /proc/sys/vm/dirty_expire_centisecs
    echo 1 > /proc/sys/net/ipv4/tcp_rfc1337
    echo 10 > /proc/sys/vm/swappiness
    echo never > /sys/kernel/mm/transparent_hugepage/enabled
    echo never > /sys/kernel/mm/transparent_hugepage/defrag
    echo 120 > /proc/sys/net/ipv4/tcp_keepalive_time
    echo 0 > /proc/sys/vm/zone_reclaim_mode
    echo deadline > /sys/block/sda/queue/scheduler
    echo 8 > /sys/class/block/sda/queue/read_ahead_kb
    echo 1048575 > /proc/sys/vm/max_map_count

退出 vi 编辑器保存文件。

这些参数将在每次重启时设置，在所有 init 服务启动后，就在登录提示显示之前。

（/etc/rc.local文件在所有启动linux服务之后执行，如果elasticsearch作为服务在它之前启动可能不起作用，但是如果您将来需要，此方法在其他设置中很有用，或者您可以像这样使用通过将它们放在您的 elasticsearch init 脚本中，因为 init 脚本以 root 身份运行，所以它与上面在 init 脚本中使用的语法相同）

您也可以立即复制它们并粘贴它们以进行即时更改。上面的参数在我的 apache cassandra 服务器上是有效的、经过调整和运行的。如果您愿意，可以尝试将它们作为调整您的起点。

使它们永久化的第二种方法：

现在将在 linux 上的任何启动服务之前设置参数。

编辑/etc/sysctl.conf，把参数放在里面

 vm.max_map_count=1048575
 vm.zone_reclaim_mode=0
 vm.dirty_background_bytes=220000000
 vm.dirty_background_ratio=0
 vm.dirty_bytes=320000000
 vm.dirty_ratio=0
 vm.swappiness=10

继续使用其他方法，保存/etc/sysctl.conf，重新启动服务器以应用更改，或执行：sysctl -p以在不重新启动的情况下应用更改。它们将在重新启动后永久存在。

以上两种方法是最常见的。还有另一个，它可能对你有用，它是通过使用sudo，几乎就像你在做的那样：

代替：

  sudo sysctl -w vm.max_map_count=262144

尝试：

  echo 262144 | sudo tee /proc/sys/vm/max_map_count

它适用于 ubuntu。

核实：

   user@naos:~$ cat /proc/sys/vm/max_map_count
   262144

希望我在某种程度上有所帮助，至少通过提供 3 种不同的选项来解决问题，因为您的问题已经快一年了；）

问候，拉斐尔·普拉多

Answer 2

我认为您的“虚拟机”实际上是一个 OpenVZ 容器（您可以通过运行来验证这一点virt-what）。

在这种情况下，您不能更改vm.max_map_countsysctl 或许多其他选项。值是固定的。

这是 elasticsearch 的一个众所周知的问题（问题 #4978）。不仅仅是 Elasticsearch。众所周知，Java 应用程序在各种 OpenVZ 提供程序上表现不佳，主要是因为主机通常没有经过很好的调整，而您对此无能为力。关于该问题的一位评论者准确地回应了我的建议：

joshuajonah 于 2015 年 10 月 20 日发表评论
这太疯狂了。我想我要改用 KVM VPS。