Невозможно изменить vm.max_map_count для эластичного поиска

Вы почти там, не имеет значения, виртуальная машина или физическая машина, эти параметры всегда можно изменить.

Я покажу 3 метода.

Некоторая предварительная информация:

1) Лучше всего выполнять от имени пользователя root, если это возможно.

2) /proc в unix- это не настоящая файловая система, это файловая система ядра в памяти, но она выглядит как обычная файловая система на диске. Вы можете назвать это "поддельной файловой системой" или "специальной файловой системой", вы не можете редактировать эти поддельные файлы с помощью 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, настройки становятся активными мгновенно. Но они не сохраняются после перезагрузки. Вы можете поиграть со значениями и измерить изменения в производительности в asticsearh или любом другом приложении или метриках системы. Настройте свою систему, запишите значения на бумаге, сохраните лучшие значения. При любой ошибке перезагрузите компьютер, и все они вернутся к исходным значениям и начнут снова, пока все желаемые значения не станут оптимальными. В /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, он может не работать, если asticsearch запускается до его использования в качестве службы, но этот метод может быть полезен при другой настройке, если вам это потребуется в будущем, или вы можете использовать его следующим образом поместив их в ваш скрипт initsearch 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 различных варианта решения проблемы, так как ваш вопрос уже почти год;)

С уважением, Рафаэль Прадо

Я думаю, что ваша "виртуальная машина" на самом деле является контейнером OpenVZ (что вы можете проверить это, запустив virt-what).

В этом случае вы не можете изменить vm.max_map_count sysctl или многие другие. Значения являются фиксированными.

Это хорошо известная проблема с asticsearch ( выпуск № 4978). Это не просто Elasticsearch. Известно, что Java-приложения плохо работают на различных провайдерах OpenVZ, в основном потому, что хосты часто плохо настроены и с этим ничего не поделаешь. Один комментатор по этому вопросу повторил то, что было бы моей рекомендацией:

joshuajonah прокомментировал 20 октября 2015 г.
Это безумие. Я думаю, что я собираюсь перейти на KVM VPS.

Вы можете следовать официальным инструкциям:

sysctl -w vm.max_map_count=262144

Чтобы сделать изменение постоянным, обновите параметр vm.max_map_count в /etc/sysctl.conf

См. https://www.elastic.co/guide/en/elasticsearch/reference/current/vm-max-map-count.html