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

предыстория

У меня естьasticsearch и SugarCRM7, работающие на CentOS 6.5. Каждый день я сталкиваюсь с одной и той же проблемой: ошибка Java OutOfMemory. Это происходит из-за малого значения vm.max_map_count, 65530, только когда рекомендуется 262144.

проблема

Проблема в том, что vm.max_map_count кажется неизменным:

1. Смена под рутом

   sudo sysctl -w vm.max_map_count=262144
   

   возвращается

   ошибка: отказано в доступе к ключу vm.max_map_count

   Пока

   ps aux | grep java
   

   Возвращает только процесс grep

2. Изменение при запуске эластичного поиска

   sudo service elasticsearch start
   

   Возвращает ошибку тоже

   ошибка: отказано в доступе к ключу vm.max_map_count

   Начальный поиск: [OK]

3. Ручные изменения через файл (грязный-грязный хак):

   sudo vi /proc/sys/vm/max_map_count
   

   Тоже не работает:

   "/ proc / sys / vm / max_map_count" [только для чтения] 1L, 6C

   - INSERT - W10: Предупреждение: изменение файла только для чтения

   E45: опция «только для чтения» установлена ​​(добавить! Для переопределения)

   "/ proc / sys / vm / max_map_count" E212: не удается открыть файл для записи

   Пока

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

   Возвращает

   -rw-r - r-- 1 корневой корень 0 апр. 10 09:36 max_map_count

   (Но я думаю, что это нормально для linux, говорящего о каталоге / proc)

Итак, как я могу изменить значение этой переменной? Повторно запускатьasticsearch каждую ночь не очень хорошая идея ... Или, по крайней мере, может кто-то знает, почему эта ошибка происходит?

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

Я покажу 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 запускается до его использования в качестве службы, но этот метод может быть полезен при другой настройке, если вам потребуется в будущем, или вы можете использовать так поместив их в свой сценарий инициализации эластичного поиска, потому что сценарий инициализации запускается от имени пользователя 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 или многие другие. Значения являются фиксированными.

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

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

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

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.