内存映射提升树所需的估计大小

Question

我们有一个场景，其中我们动态增长用于boost的r树几何索引的内存映射文件。我们还利用了boost的进程间内存映射文件api。

已经根据取消映射文件，增长和重新映射的方式对机械进行了分类，所有这些都有效。

到目前为止，我们已经尝试过以我们的坐标固有尺寸的10倍高估尺寸，这种方法虽然有效，但是在用du进行检查时却被高估了。

是否有某种方法可以预测（最坏情况还是最精确的情况）在给定对象数量的情况下，我们要求映射文件增长多少大小？低估（例如，系数为5）最终导致堆栈崩溃...

谢谢

Answer 1

从纯粹的意义上讲，这个问题与boost-inteprocess无关。

您想了解分配模式（不仅要了解净分配量，而且还要了解由于碎片导致的有效“池”使用。

您可以做的是分配器使用情况的统计（好问题：是否有某种统计信息收集分配器适配器？）并进行计算。

当然，您会处于近似范围内，但是如果进行了足够的模拟运行，您应该具有可用的信息。

作为最后的选择，Boost Geometry的源/开发者将是要问的人。

其他角度

关于Boost Interprocess，我们不知道您在使用什么。我假设managed_mapped_file /managed_heap_memory/ managed_external_buffer。请注意，将它们与默认的内存分配策略（rbtree_best_fit）一起使用时，可能会产生相当大的碎片或分配开销（对于基于节点的容器，可能包括rtree）。

相关示例：

• Bad alloc is thrown

这立即为您提供一些使用思路：

• shm.get_free_memory()获取段中剩余空间的原始数字
• 在托管内存段之外使用rtree时，使用内存分析器（如Valgrind Massif）>

开箱即用：

• 最后，请不要忘记分配一个稀疏文件（即使是10 GiB）并使用共享内存管理器分配到它中可能非常便宜：只有实际使用的页面才会被提交到磁盘，因此实际磁盘使用量将与actual required大小紧密匹配。

  备用文件很神奇。

---