java - Terracotta 的性能和技巧

Question

大约一个月前发现 Terracotta 后，我刚刚开始学习如何使用它。这是一项非常酷的技术。

基本上我想做的是:

我的根(记录系统)是一个 ConcurrentHashMap。

主要的 Instrumented 类是一个“JavaBean”，它有 30 个左右的字段，我希望它们存在于 HashMap 中。

Hashmap 中大约有 20000 个这样的 JavaBean。

每个 bean 有(至少)5 个字段，每 5 秒更新一次。

(我为此使用 Terracotta 的原因是因为这些 JavaBeans 需要可以跨 JVM 和节点访问。)

谁有比我更丰富的 TC 经验？性能是关键。

还有其他类似应用的例子吗？

Answer 1

您可能会发现在一个锁定范围内批处理多个更改会执行得更好。每个同步块(synchronized block)/方法形成一个必须发送到服务器(并可能返回到其他节点)的写事务(假设您使用写锁)。通过更改一堆字段，可能是在一个锁下的一堆对象上，您可以减少创建事务的开销。至少可以玩的东西。

分区也是提高性能的关键方法。只需将更改发送到实际使用对象的节点。因此，如果您可以划分哪些节点通常接触特定对象，从而减少必须在集群周围发送的更改数量，从而提高性能。

unnutz 关于使用 CHM 或 CSM 的建议很好。 CHM 允许更高的并发性(因为每个内部段都可以被锁定并同时使用)——确保也尝试使用更大的段数。 CSM 每个条目实际上有一个锁，因此在 N 大小的表中实际上有 N 个分区。这可以大大减少锁争用(以管理更多内部锁对象为代价)。 CSM 即将发生的变化将使锁管理成本大大降低。

通常我们发现好的策略是:

1. 构建性能测试(应该是多线程和多节点的，并且类似于您的应用(或您的实际应用!)
2. 调整对象 - 查看开发控制台中的集群对象图以找到根本不需要集群的对象 - 有时会意外发生(使用 transient 字段删除或剪切集群)。有时您可能会将一个 Date 聚类到一个 long 会做的地方。变化很小，但这是每个 map 条目一个对象，这可能会有所不同。
3. 调整锁 - 使用开发控制台中的锁分析器查找热锁或太窄或太宽的锁。集群统计记录器也可以帮助查看事务大小。
4. 调整 GC 和 DGC - 调整 JVM 垃圾收集，然后通过打开更改年轻代 gc 的频率来调整 Terracotta 分布式 GC。
5. 调整 TC 服务器 - 此处需要进行许多非常详细的调整，但在调整上述内容之前通常不值得。

欢迎调用 Terracotta forums 询问以及 - 所有工程、现场工程、产品管理人员都会观看并在那里回答。