Apache Ignite 2.4 数据分区不均匀导致节点内存不足和崩溃答案

【问题标题】：Apache Ignite 2.4 uneven partitioning of data causing nodes to run out of memory and crashApache Ignite 2.4 数据分区不均匀导致节点内存不足和崩溃
【发布时间】：2018-05-08 23:41:13
【问题描述】：

环境：

在 Amazon Linux 上运行的 Apache Ignite 2.4。虚拟机是 16CPU/122GB 内存。那里有足够的空间。
5 个节点，每个 12GB
cacheMode = PARTITIONED
backups = 0
OnheapCacheEnabled = true
atomicityMode = ATOMIC
rebalacneMode = SYNC
rebalanceBatchSize = 1MB
copyOnread = false
rebalanceThrottle = 0
rebalanceThreadPoolSize = 4

基本上，我们有一个进程在启动时填充缓存，然后从 Kafka 接收定期更新，将它们传播到缓存。

缓存中的元素数量随着时间的推移或多或少是稳定的（只是有一点波动，因为我们混合了创建、更新和删除事件），但我们注意到数据在不同的节点非常不均匀，其中一个节点的密钥数量（和内存利用率）至少是其他节点的两倍。随着时间的推移，该节点要么耗尽内存，要么开始执行很长时间的 GC，并与集群的其余部分失去联系。

我的期望是 Ignite 会平衡不同节点之间的数据，但现实情况完全不同。我在这里错过了什么吗？为什么我们会看到这种不平衡，我们该如何解决？

提前致谢。

【问题讨论】：

如何“非常不平衡”？ Ignite 使用 Rendezvous 散列，在默认设置下，您预计会有大约 5% 的差异。如果您看到更多，则您的关联键可能是倾斜的（如果有的话）。
利用率最高的节点的条目数是利用率最低的节点的两倍。我没有定义任何关联键，只是使用默认值。
@AlA 可能由于某些未知原因，您将键映射到分区不均匀。我会考虑更改哈希码或自定义关联函数：apacheignite.readme.io/docs/…
刚刚在我们的集群中发现了完全相同的问题。多达 40 个节点仍然非常不平衡 - 人口最多和人口最少的节点之间存在 2.2 倍的差异。
@Dmitriy，“标准”Java 哈希函数应该提供良好的分布。尽管缓存的对象大小不一，但缓存对象的数量很大（数百万），键上的哈希函数应该提供数据的随机分布。如果其中一个节点的数据明显多于其他节点，节点不应该自动重新分区数据吗？

标签： out-of-memory ignite rebalancing

【解决方案1】：

归根结底，尽管我们的哈希函数具有良好的分布，但默认的亲和函数并未在集群中的节点之间产生良好的键分布（因此，内存）。我们用一个非常幼稚的 (partition # % # of nodes) 替换它，这大大改善了分布（小于 2% 的方差）。

这不是一个通用的解决方案；它对我们有用，因为我们的整个集群都在一个虚拟机中，而且我们不使用复制。对于跨越虚拟机边界和复制的大型集群，必须将复制的数据保存在不同的服务器中，而幼稚的方法不会削减它。

【讨论】：