vm.max_map_count и mmapfs

Question

Каковы плюсы и минусы увеличения vm.max_map_count от 64k ​​до 256k?

Имеет ли vm.max_map_count = 65530 imply -> 64k адресов * 64kb размер страницы = до 4 ГБ данных можно ссылаться на процесс?

И если я превысил 4 ГБ - адресное пространство из-за лимита vm.max_map_count, будет ли ОС выходить на страницу с некоторыми более старыми доступными данными индекса?

Может быть, мое выше понимание не является правильным, как кэш-FS может быть довольно огромным

Как это ограничение результат в ООМ?

Я отвечал на подобный вопрос о elasticsearch контексте в https://discuss.elastic.co/t/mmapfs-and-impact-of-vm-max-map-count/55568

Answer 1

Отвечая на мой собственный вопрос на основе дальнейшего копания и ответа от Уве Schindler - Lucene PMC

Размер страницы не имеет ничего общего с max_map_count , Это число отображений. Lucent's MMapDirectory отображает в порциях до 1 гигабайт. Количество отображений для этого зависит от от количества сегментов (количество файлов в индексной директории) и их размер. Типичный индекс с 40 файлами в индексном каталоге, все из них менее 1 гигабайта требуют 40 сопоставлений. Если индекс больше, то имеет 40 файлов, и большинство сегментов имеют 20 гигабайт, а затем занимает до 800 сопоставлений.

Резонанс, который рекомендует пользователям Elasticsearch поднимать max_map_count из-за структуры их клиентов. Большинство пользователей Logstash имеют облако Elasticsearch с 10 000 индексами, возможно, очень большое, поэтому число картографических данных может быть ограничено.

Я хотел бы предложить, чтобы не изменить настройки по умолчанию, если вы не получите IOExceptions о «карте не удалась» (обратите внимание: это не приведет к OOMS с последними версиями Lucene, как это обрабатывается внутри !!!!)

Подкачка ОС не имеет ничего общего с отображаемым количеством файлов. Максимальное значение max_map_count - это ограничение на количество сопоставлений, которое может быть использовано в . Для отображения требуется один кусок до 1 гигабайта, который имеет mmapped. Paging в ОС происходит на гораздо более низком уровне, он будет менять любую часть в соответствии с размером страницы этих кусков независимо друг от друга: размер порции = страница

Резюме - Пожалуйста, поправьте меня, если я ошибаюсь, в отличие от того, что предлагает документация. Не думайте, что необходимо увеличить max_map_count во всех сценариях

ES 2.x - В режиме FS по умолчанию (гибридный nio + mmap) только файлы .dvd и .tim (возможно, точки тоже) имеют mmaped, и это будет допустим ~ 30000 осколков на узел.

ES 5.x - есть дросселирование сегмента, поэтому, хотя по умолчанию перемещается в mmapfs, значение по умолчанию 64k по-прежнему может работать нормально.

Это может быть полезно, если вы планируете использовать mmapfs и иметь> 1000 обрывов на узел.(я лично вижу, что многие проблемы с помехами ползут с высокими осколками/узлами)

Магазин mmapfs - только если в магазине есть mmapfs, и каждый узел хранит> 65000 файлов сегмента (или 1000+ осколков), этот лимит будет включен. скорее добавьте больше узлов, чем такое массивное количество осколков на узел на mmapfs