vm.max_map_count和mmapfs

时间:2016-07-14 21:45:08

标签: unix memory-management elasticsearch lucene mmap

将vm.max_map_count从64k增加到256k有什么优缺点?

vm.max_map_count = 65530是否意味着 - > 64k地址* 64kb页面大小=进程可以引用高达4GB的数据吗?

如果我超过4GB - 由于vm.max_map_count限制而导致的可寻址空间,操作系统是否需要寻找一些较旧的访问索引数据?

也许我的上述理解不正确,因为FS缓存可能非常庞大

此限制如何导致OOM?

我在https://discuss.elastic.co/t/mmapfs-and-impact-of-vm-max-map-count/55568

上发布了关于弹性搜索背景的类似问题

1 个答案:

答案 0 :(得分:1)

根据Uwe Schindler的进一步挖掘和回复解答我自己的问题 - Lucene PMC

  

页面大小与max_map_count无关。它是分配的映射数。 Lucene的MMapDirectory映射到   部分最多1 GiB。因此,映射的数量是相关的   关于段的数量(索引目录中的文件数)和   他们的大小。所有索引目录中包含40个文件的典型索引   小于1 GiB的它们需要40个映射。如果指数较大,   有40个文件,大多数段有20千兆字节,那么它可以   最多需要800个映射。

     

Elasticsearch人员建议提高max_map_count的原因是他们的客户结构。大多数Logstash   用户拥有Elasticsearch云,每个云可能有10,000个索引   非常大,因此映射的数量可能会受到限制。

     

我建议不要更改默认设置,除非您获得有关"映射失败"的IOExceptions。 (请注意:它不会导致   最近使用Lucene版本的OOM在内部处理!!!!)

     

操作系统的分页与映射文件计数无关。 max_map_count只是总共有多少映射的限制   用过的。映射需要一个最多1 GiB的块,该块是mmapped。分页   在操作系统发生在更低的水平,它将交换任何部分   根据这些块的页面大小独立:chunk!=   页面大小

总结 - 如果我错了,请纠正我,不像文档建议的那样。不要认为在所有场景中都需要增加max_map_count

ES 2.x - 在默认(混合nio + mmap)FS模式下,只有.dvd和.tim文件(也许是点)是mmaped,每个节点允许~30000个分片。

ES 5.x - 存在段限制,所以尽管默认移动到mmapfs,默认值64k仍然可以正常工作。

如果您计划使用mmapfs并且具有>这可能很有用。每个节点1000个分片。 (我个人看到很多关于高分片/节点的问题)

mmapfs store - 仅当商店为mmapfs并且每个节点存储>这个限制会有65000个段文件(或1000多个分片)。我宁愿添加更多节点,而不是mmapfs上每个节点有如此大量的分片