java map 内存分配_java-OpenHFT ChronicleMap的内存分配和限制

这篇文章很可能是OpenHFT常见问题的很好的候选人.

我正在使用ChronicleMap进行思考,但有很多问题.我确信大多数正在研究此产品的初级程序员也有类似的考虑.

您能否解释一下如何在此API中管理内存？

ChronicleMap宣称可以使用一些出色的TB堆外内存资源来处理其数据,我希望对此有一个清晰的认识.

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

接下来的相关问题与ChronicleMap的实现有关.

我的理解是,每个ChronicleMap都会分配其工作的内存块,并且当我们可以准确预测所传递的数据量时,可以实现最佳性能/内存使用率.但是,这是一个动态的世界.

让我们举一个(夸张但可能的)示例：

假设有一个K(关键)“城市”及其V(值)-“描述”(城市)的地图,并且允许用户对描述长度进行较大限制.

第一个用户输入：K =“阿姆斯特丹”,V =“自行车之城”,该输入用于声明地图

-它为这样的货币对设定了先例：

ChronicleMap cityPostalCodes = ChronicleMap

.of(CharSequence.class, CharSequence.class)

.averageKey("Amsterdam")

.averageValue("City of bicycles")

.entries(5_000)

.createOrRecoverPersistedTo(citiesAndDescriptions);

现在,下一个用户被带走并撰写有关布拉格的分析

他传给：K =“布拉格”,V ＝“ 100座塔楼之城位于欧洲的重地……等等,等等……百万个单词……”

现在,程序员原本希望最多5_000个条目,但是它变得一发不可收拾,并且有成千上万个条目.

ChronicleMap是否会为这种情况自动分配内存？如果是,是否有更好的方法声明此动态解决方案的ChronicleMaps？如果没有,您会推荐一种方法(在代码示例中最好)如何最好地处理这种情况吗？

如何持久化归档？

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相反-我分配了小块(.entries(10)、. averageValueSize(10),实际使用情况是条目的1_000_000s,平均大小= 1_000s字节.

怎么了？：

解决方法:

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将分配内存,直到插入的实际条目数除以通过ChronicleMappBuilder.entries()配置的数目不大于配置的ChronicleMapBuilder.maxBloatFactor().如果您将地图创建为

ChronicleMap 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.

现在的解决方案是至少大致正确地通过entrys()(和averageKey()和averageValue())配置编年史地图的未来大小.

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个字节*低估因子.因此,如果实际平均输入大小(键值)很小,例如e. G. 50个字节,而您将其配置为20个字节,则会浪费〜8 * 50/20 = 20个字节,即40％.平均入口尺寸越大,浪费越少.

键/值大小过高：如果仅配置键和值平均大小,而不直接配置actualChunkSize(),则实际块大小将自动选择在平均条目大小(键值)的1/8至1/4之间.实际块大小是编年史地图中的分配单位.因此,如果您将平均条目大小配置为〜1000字节,则实际块大小将在125到250字节之间选择.如果实际的平均条目大小仅为100字节,则将浪费很多空间.如果高估很小,则预期的空间损失将限制为数据大小的大约20％.

因此,如果您担心自己可能会高估平均键/值大小,请显式配置actualChunkSize().

被低估的条目数：上文已讨论.没有特别的空间浪费,但编年史地图的运行速度较慢,低估的可能性更大.

条目被高估的数量：哈希查找区域中的内存被浪费,每个条目〜8个字节*高估因子.有关实际的平均输入数据大小,请参见上面的键/值大小低估部分,以了解其优劣.

标签：memory,java,chronicle-map

来源： https://codeday.me/bug/20191026/1938622.html