OpenHFT ChronicleMap内存的限制和限制

这篇文章可能是OpenHFT常见问题的一个很好的候选人。OpenHFT ChronicleMap内存的限制和限制

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

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

ChronicleMap宣布了一些显着的TBs堆外存储器资源可用于处理其数据，我想清楚的看到这一点。

让我们来找一个带有500GB HD和4GB RAM的笔记本电脑的程序员。在这种情况下，纯数学赛车 - 可用“交换”内存的总资源为504GB。让我们给OS和其他程序一半，我们剩下250GB高清和2GB内存。你能否详细说明实际可用的内存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？如果不是，你会推荐一种方法（最好在代码示例中）如何最好地处理这种情况？

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

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

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

以下哪些适用于ChronicleMap？

如果我分配大块（.entries(1_000_000)，.averageValueSize(1_000_000)和实际使用情况是 - 项= 100，和平均值大小= 100。

，会发生什么？：

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

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 - I分配小块（.entries(10)，.averageValueSize(10)和实际使用是条目1_000_000s，和平均值大小=字节1_000s 会发生什么情况？：

。

来源

2016-09-04 Felix

你好。请记住，我们的社区由不同性别的人组成，如果您将他们称为“先生们”，有些人可能会感到被排除在外。无论如何，我们宁愿帖子不要包含任何称呼。谢谢！ – halfer

让我们坐下来与500GB HD和4GB内存的笔记本电脑程序员在这种情况下，纯数学赛斯 - 。可用的“交换”内存资源总量为504GB让我们给操作系统和其他软件半我们只剩下250GB的HD和2GB的内存，您能详细说明一下实际可用的内存吗ChronicleMap可以根据可用的资源分配数量urces？

在这样的条件下，Chronicle Map将非常缓慢，平均每次使用Chronicle Map进行2次随机磁盘读写操作（总共4次随机磁盘操作）。传统的基于磁盘的数据库引擎（如RocksDB或LevelDB）在数据库大小比内存大得多时应该更好。

现在的程序员曾预计最大5_000条目，但它得到了他的手，并有好几千个条目。

ChronicleMap会自动为这种情况分配内存吗？如果是，是否有更好的方法来为这个动态解决方案声明ChronicleMaps？如果不是，你会推荐一种方法（最好在代码示例中）如何最好地处理这种情况？直到通过ChronicleMappBuilder.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。

然而，纪事地图作品越来越慢，当实际规模的增长远远超出了配置的大小，所以最大可能maxBloatFactor()被人为限制在1000

的解决方案，现在是配置纪事未来的规模至少近似正确地通过entries()（和averageKey()和averageValue()）映射。

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

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

键/值大小欠估计：空间被浪费在hash lookup area，〜8个字节*低估因子，每个条目。所以如果实际的平均条目尺寸（键+值）很小，那么它可能是非常糟糕的，例如， G。 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-19 16:30:30 leventov

OpenHFT ChronicleMap内存的限制和限制

回答

相关问题