Невозможно изменить vm.max_map_count для elasticsearch

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

Я покажу 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 настройки мгновенно становятся активными. Но они не сохраняются после перезагрузки. Вы можете поиграть со значениями и измерить изменения производительности на эластичный или любые другие показатели приложения или системы. Настройте свою систему, запишите значения на бумаге, сохраните лучшие значения. При любой ошибке перезагрузитесь, и все они вернутся к исходным значениям, и начните снова, пока все желаемые значения не станут оптимальными. В / 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 init скрипт, потому что скрипт инициализации запускается от имени пользователя 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 sysctl -w vm.max_map_count=262144

пытаться:

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

Работает на убунту.

Проверить:

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

Надеюсь, я каким-то образом помог, по крайней мере, предоставив 3 разных варианта решения проблемы, так как вашему вопросу почти год;)

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

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

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

Это хорошо известная проблема с elasticsearch (Выпуск # 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