3

这篇文章可能是 OpenHFT 常见问题的一个很好的候选者。

我正在玩 ChronicleMap 考虑它的一个想法，但有很多问题。我相信大多数研究这个产品的初级程序员都有类似的考虑。

您能解释一下这个 API 是如何管理内存的吗？

ChronicleMap 宣称有一些出色的 TB 堆外内存资源可用于处理其数据，我想对此有一个清晰的认识。

让我们来看看一个拥有 500GB HD 和 4GB RAM 的笔记本电脑的程序员。在这种情况下，纯数学 sais - 可用“交换”内存的总资源为 504GB。让我们将操作系统和其他程序减半，剩下 250GB HD 和 2GB RAM。您能否详细说明 ChronicleMap 可以相对于可用资源分配的实际可用内存？

下一个相关问题与 ChronicleMap 的实现有关。

我的理解是，每个 ChronicleMap 分配它使用的内存块，并且当我们可以准确预测通过的数据量时，可以实现最佳性能/内存使用。然而，这是一个动态的世界。

让我们设置一个（夸张但可能的）示例：

假设 K（关键）“城市”及其 V（值）-“描述”（城市）的地图，并允许用户对描述长度有很大限制。

第一个用户输入: K = "Amsterdam"，V = "City of bicycles"这个条目用于声明地图 - 它为这样的对设置了先例：

ChronicleMap<Integer, PostalCodeRange> cityPostalCodes = ChronicleMap
    .of(CharSequence.class, CharSequence.class)
    .averageKey("Amsterdam")
    .averageValue("City of bicycles")
    .entries(5_000)
    .createOrRecoverPersistedTo(citiesAndDescriptions);

现在，下一个用户被带走并写了一篇关于布拉格的分析他传递给：K = "Prague"，V = "City of 100 towers is located in the hard of Europe ... blah, blah... million words ..."

现在程序员预计最多 5_000 个条目，但它失去了他的控制，并且有数千个条目。

ChronicleMap 会为这种情况自动分配内存吗？如果是的话，有没有更好的方法为这个动态解决方案声明 ChronicleMaps？如果不是，您会推荐一种方法（最好的代码示例）如何最好地处理这种情况？

这如何与持久性文件一起工作？

ChronicleMaps 会耗尽我的 RAM 和/或磁盘空间吗？避免这种情况的最佳做法？

换句话说，请解释在低估和高估值（和/或键）长度和条目数的情况下如何管理内存。

哪些适用于 ChronicleMap？

  1. 如果我分配大块 ( .entries(1_000_000)，.averageValueSize(1_000_000)实际使用量是 - Entries = 100，Average Value Size = 100。

怎么了？：

1.1。- 一切正常，但会有大块浪费 - 未使用？

1.2. - 一切正常，未使用的内存可用于：

1.2.1 - 编年史地图

1.2.2 - 给定线程使用 ChronicleMap

1.2.3 - 给定进程

1.2.4 - 给定 JVM

1.2.5 - 操作系统

1.3. - 请解释未使用的内存是否发生其他情况

1.4. - 过大的声明对我的持久性文件有什么影响？

  1. 与案例1相反 - 我分配了小块 ( .entries(10)，.averageValueSize(10)实际使用量为 1_000_000s 个条目，平均值大小 = 1_000s 个字节。会发生什么？：
4

1 回答 1

5

让我们来看一个拥有 500GB HD 和 4GB RAM 笔记本电脑的程序员。在这种情况下，纯数学 sais - 可用“交换”内存的总资源为 504GB。让我们将操作系统和其他程序减半，剩下 250GB HD 和 2GB RAM。您能否详细说明 ChronicleMap 可以相对于可用资源分配的实际可用内存？

在这种情况下，Chronicle Map 将非常慢，在使用 Chronicle Map 的每个操作中平均有 2 次随机磁盘读取和写入（总共 4 次随机磁盘操作）。当数据库大小远大于内存时，传统的基于磁盘的数据库引擎，如RocksDB或LevelDB应该会更好地工作。

现在程序员预计最多 5_000 个条目，但它失去了他的控制，并且有数千个条目。

ChronicleMap 会为这种情况自动分配内存吗？如果是的话，有没有更好的方法为这个动态解决方案声明 ChronicleMaps？如果不是，您会推荐一种方法（最好的代码示例）如何最好地处理这种情况？

Chronicle Map 将分配内存，直到插入的实际条目数除以配置的数量ChronicleMapBuilder.entries()不高于配置的数量ChronicleMapBuilder.maxBloatFactor()。例如。如果您将地图创建为

ChronicleMap<Integer, PostalCodeRange> cityPostalCodes = ChronicleMap
    .of(CharSequence.class, CharSequence.class)
    .averageKey("Amsterdam")
    .averageValue("City of bicycles")
    .entries(5_000)
    .maxBloatFactor(5.0)
    .createOrRecoverPersistedTo(citiesAndDescriptions);

当大小约为 25 000 时，它将开始IllegalStateException尝试插入新条目。

但是，当实际大小远远超出配置大小时，Chronicle Map 的运行速度会逐渐变慢，因此最大可能maxBloatFactor()被人为限制为 1000。

现在的解决方案是通过entries()(and averageKey(), and averageValue()) 至少大致正确地配置 Chronicle Map 的未来大小。

预先配置合理的编年史地图大小的要求被认为是一个可用性问题。有一种方法可以解决这个问题，它在项目路线图上。

换句话说，请解释在低估和高估值（和/或键）长度和条目数的情况下如何管理内存。

键/值大小低估：在哈希查找区域中浪费了空间，每个条目约 8 字节 * 低估因子。因此，如果实际的平均条目大小（键 + 值）很小，例如 50 字节，并且您将其配置为 20 字节，则可能会非常糟糕，您将浪费 ~ 8 * 50 / 20 = 20 字节，或 40%。平均入口尺寸越大，浪费越小。

高估键/值大小：如果只配置键和值平均大小，而不是actualChunkSize()直接配置，则实际块大小会自动选择平均条目大小（键 + 值）的 1/8 到 1/4 之间。实际的块大小是 Chronicle Map 中的分配单元。因此，如果您将平均条目大小配置为 ~ 1000 字节，则实际块大小将在 125 到 250 字节之间选择。如果实际的平均条目大小仅为 100 字节，则会丢失大量空间。如果高估很小，则预期的空间损失将限制在数据大小的 20% 左右。

因此，如果您担心您可能高估了平均键/值大小，请actualChunkSize()显式配置。

条目数低估：上面讨论过。没有特别的空间浪费，但 Chronicle Map 运行速度较慢，被低估的情况越糟。

条目数高估：在哈希查找区域中浪费了内存，每个条目约 8 字节 * 高估因子。请参阅上面的键/值大小低估部分，了解它的好坏程度，具体取决于实际的平均条目数据大小。

于 2017-03-19T16:30:30.960 回答