java - JVM 垃圾收集和内存中 Java 数据库

Question

我们正在评估一些基于 Java 的内存数据库，例如 Hazelcast 和 VoltDB。如果我们跨多个服务器复制数据，两个节点的 GC 有多大可能同时命中服务器？

例如，我们有两个具有 500 GB 内存的节点，并且我们知道一旦 GC 启动，它将极大地影响我们的性能。那么两个节点中的 GC 一起命中的概率是多少？

换句话说——是否可以通过某些配置来防止 GC 同时命中两个节点？我们预计每秒大约 15k 个请求的吞吐量，因此通过跨 4 个或更多节点的分布，我们可以一次承受一个节点的命中，从而获得 25% 的性能命中和相应的大小。

Answer 1

正如 Ben 指出的那样，VoltDB 将所有数据存储在堆外。堆仅在事务路由和存储过程执行期间用于暂存空间，因此每个事务的数据仅存在几毫秒，并且大多数在 GC 期间永远不会被提升或存在。实际的 SQL 执行也在堆外进行，因此临时表不会产生垃圾。

VoltDB 中的 GC 应该代表 < 1% 的执行时间。您可以通过适当调整年轻一代的大小来选择百分比。以该吞吐量进行的真实世界部署每隔几秒就会执行一次新生代 GC，并且 GC 应该只阻塞一位数毫秒。老一代 GC 应该很少发生，大约几天一次，并且应该只阻塞 10 毫秒。如果您想确保它们发生在非高峰时段，您可以手动调用它们。

我不明白为什么跨节点的并发 GC 很重要。最坏的情况是，如果作为事务依赖项的每个节点都背靠背执行 GC，那么延迟就是所涉及节点数量的总和。我建议您测量并查看它是否真的会影响对您重要的一段时间内的吞吐量。

我们在最新版本的延迟方面投入了大量精力，我可以分享其中一个 KPI。

这是 32 字节键和 1024 字节值的 50/50 读/写的 3 节点基准测试。有一个客户端有 50 个线程。基准测试期间出现节点故障，基准测试运行了 30 分钟。这不是吞吐量基准，因此只有一个线程数较少的客户端实例。

Average throughput:               94,114 txns/sec
Average latency:                    0.46 ms
10th percentile latency:            0.26 ms
25th percentile latency:            0.32 ms
50th percentile latency:            0.45 ms
75th percentile latency:            0.54 ms
90th percentile latency:            0.61 ms
95th percentile latency:            0.67 ms
99th percentile latency:            0.83 ms
99.5th percentile latency:          1.44 ms
99.9th percentile latency:          3.65 ms
99.999th percentile latency:       16.00 ms

如果您进一步分析这些数字并与其他事件和指标相关联，您会发现 GC 即使在高百分位数时也不是一个因素。 Hotspot 的 ParNew 收集器非常好，如果你可以保持你的工作集较小并避免提升，即使它在延迟方面很糟糕，但在吞吐量方面也很好。

在堆上存储数据的数据库确实必须更加关注 GC 暂停。在 VoltDB，我们只关心它们，因为我们经常根据最大暂停时间而不是平均暂停时间或某个百分位的暂停时间来评估。