java - OpenHFT Chronicle Map 内存分配和限制

Question

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

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

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

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

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

接下来的相关问题是关于ChronicleMap的实现。

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

让我们举一个(夸张但可能的)例子:

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

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

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。 - 一切正常，但会有大量浪费的 block - 未使用？

1.2。 - 一切正常，未使用的内存可用于:

1.2.1 - ChronicleMap

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_000 字节。 会发生什么？:

Answer 1

Lets get down to a programmer with a laptop of 500GB HD and 4GB RAM. In this case pure math sais - total resource of 'swapped' memory available is 504GB. Let's give the OS and other programs half and we are left with 250GB HD and 2GB RAM. Can you elaborate on the actual available memory ChronicleMap can allocate in numbers relative to available resources?

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

---

Now the programmer had expected max 5_000 entries, but it gets out of his hands and there are many thousands of entries.

Does ChronicleMap allocate memory automatically for such cases? If yes is there some better approach of declaring ChronicleMaps for this dynamic solution? If no, would you recommend an approach (best in code example) how to best handle such scenarios?

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

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()(和averageKey()，以及averageValue()) 至少大致正确。

提前配置合理的 Chronicle Map 大小的要求被认为是一个可用性问题。 There is a way to fix this and it's on the project roadmap.

---

In other words, please explain how memory is managed in case of under-estimation and over-estimation of the value (and/or key) lengths and number of entries.

键/值大小低估: hash lookup area 中的空间被浪费了, ~ 8 字节 * 低估因子，每个条目。因此，如果实际平均条目大小(键 + 值)很小，则可能会很糟糕，例如。 G。 50 个字节，而您将其配置为 20 个字节，您将浪费 ~ 8 * 50/20 = 20 个字节，或 40%。平均条目大小越大，浪费越小。

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

因此，如果您担心可能会高估平均键/值大小，请配置 actualChunkSize()明确地。

条目数被低估:上文已讨论。没有特别的空间浪费，但 Chronicle Map 运行速度较慢，低估越严重。

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