将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上发布了关于Elasticsearch上下文的类似问题
最佳答案
在进一步挖掘和回答Uwe Schindler的基础上回答我自己的问题-Lucene PMC
总结-如果我错了，请纠正我，这与文档中所建议的不同。不要认为在所有情况下都需要增加max_map_count
ES 2.x-
在默认(混合nio + mmap)FS模式下，仅.dvd和.tim文件(也许也指向)被映射，这将允许每个节点约30000个分片。
ES 5.x-存在节流限制，因此尽管默认值移至mmapfs，但默认值64k仍可以正常工作。
如果您打算使用mmapfs，并且每个节点具有> 1000个分片，这可能会很有用。 (我个人看到许多其他问题随着高碎片数/节点而蔓延)
mmapfs存储-仅当存储为mmapfs且每个节点存储的> 65000段文件(或1000+个分片)时，此限制才会出现。我宁愿添加更多的节点，而不是在mmapfs上每个节点具有如此大量的分片
关于unix - vm.max_map_count和mmapfs，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/38384759/