将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
上发布了关于弹性搜索背景的类似问题答案 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上每个节点有如此大量的分片