无法为elasticsearch更改vm.max_map_count

史前史

我有在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'的权限被拒绝

   开始elasticsearch：[确定]

3. 通过文件进行手动更改（脏污脏物）：

   sudo vi /proc/sys/vm/max_map_count
   

   也不起作用：

   “ / proc / sys / vm / max_map_count” [只读]​​ 1L，6C

   -插入-W10：警告：更改只读文件

   E45：设置了“只读”选项（添加！以覆盖）

   “ / proc / sys / vm / max_map_count” E212：无法打开文件进行写入

   而

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

   退货

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

   （但是我想这对于Linux来说/ proc目录是正常的）

那么如何更改此变量的值？每天晚上重新启动elasticsearch并不是一个好主意……或者至少可能有人知道为什么会发生此错误？

您几乎在那儿，无论是虚拟机还是物理机都没关系，这些设置总是可以更改的。

我将展示3种方法。

一些预信息：

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

2）Unix上的/ proc不是真正的文件系统，它是内存中的内核文件系统，但看起来像是普通的磁盘文件系统。您可以将其称为“伪文件系统”或“特殊文件系统”，您无法使用vi或任何其他编辑器来编辑这些伪文件，因为它们不是文件，而是看起来像文件。多年前，我遇到了同样的问题。

但是更改它们的值很简单，只需要另一种“力学”来编辑它们即可。

我将解释：首先，需要成为root用户：（ sudo确实可以在某些发行版中工作，但不适用于您尝试过的其他发行版，第一种方法是通用的，可以在任何Linux，macOS或任何基于Unix的系统上使用希望您可以访问root密码。

在提示时继续：

    $ su root

输入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编辑器，保存文件。

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

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

您也可以立即复制它们并粘贴以进行即时更改。上面的参数有效，已调整并在我的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种不同的解决方案，因为您的问题已经存在将近一年了；）

问候，拉斐尔·普拉多

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

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

这是Elasticsearch的一个众所周知的问题（问题＃4978）。不只是Elasticsearch。众所周知，Java应用程序在各种OpenVZ提供程序上的性能均较差，主要是因为主机的调优通常很差，您对此无能为力。一位对此问题的评论者完全赞同我的建议：

joshuajonah于2015年10月20日发表评论，
这太疯狂了。我想我将转换为KVM VPS。

您可以按照官方指示进行：

sysctl -w vm.max_map_count=262144

要使更改永久更新，请更新/etc/sysctl.conf中的vm.max_map_count设置。

参见https://www.elastic.co/guide/zh-CN/elasticsearch/reference/current/vm-max-map-count.html