集群进入state，成员反复重启，客户端无法更新集群中的数据

Question

我们已经使用 Hazelcast 很多年了，但我是这个团队的新手。 我们有一个由专用 Java 应用程序组成的集群（它的唯一目的是提供集群）。 它使用 3.8.2 jars 并在 Linux (Centos 7) 上运行 JDK 1.8.0_192。

该集群管理着 static 条数据（即每天/每周更新几次）。 尽管更新可能涉及更改 2MB 的数据块。 我们在 6 个集群成员中使用 271 个分片的默认分片配置。 有 40 到 80 个客户。 每个客户端连接都应该是长期稳定的。

“偶尔”我们会遇到这样一种情况，即提供集群的 Java 应用程序反复重启，并且任何尝试写入集群的客户端都无法这样做。 由于 JVM 命令行的限制，我们过去遇到过集群应用程序用完 memory 的问题。 我们之前已经增加了这些并且（据我所知）进程重新启动不再由 OutOfMemory 异常引起。

我知道我们正在运行一个非常旧的版本，许多人会建议简单地更新。 这是我们将要开展的工作，但我们正在尝试用我们面前的系统诊断现有问题。

我在这里寻找的是关于要执行的调查类型、要运行的查询的任何建议（在系统健康时定期运行，或者在系统处于此故障状态时定期运行）。

在诊断此类问题时，我们会定期使用诸如 .netstat、tcpdump、wireshark 和 top 之类的工具（我相信还有更多工具），但无法确定此问题的令人信服的根本原因。

非常感谢任何帮助。

谢谢，戴夫

根据问题描述。 我们解决这个问题的唯一方法是完全反弹集群 - 即。 停止所有成员，然后重新启动集群。 理想情况下，我们有一个系统可以保持稳定，并且可以从导致我们看到的问题的任何“事件”中恢复。 这可能涉及配置或代码更改。

Answer 1

更新大小为 2MB 的条目会产生很多后果——大量的序列化/反序列化成本、.net 中的胖数据包、在 JVM 堆中容纳这些块的成本等。理想的条目大小是 < 30-40KB。

对于您眼前的问题，请从 GC 诊断开始。 您可以使用 jstat 调查 memory 使用模式。 如果您遇到大量完整 GC 和/或背靠背完整 GC，那么您将需要调整堆设置。 还要检查网络带宽，这通常是胖数据包通过网络传输的主要嫌疑人。

以上所有只是创可贴解决方案，你真的应该把你的条目分解成更小的条目。