集群进入成员反复重启且客户端无法更新集群中数据的状态
Cluster gets into state where members restart repeatedly and clients cannot update the data in the cluster
我们使用 Hazelcast 已经很多年了，但我是这个团队的新手。
我们有一个由专用 Java 应用程序组成的集群（它的唯一目的是提供集群）。它使用 3.8.2 jar 和 运行ning JDK 1.8.0_192 on Linux (Centos 7).
集群管理相对静态的数据（即一些更新day/week）。尽管更新可能涉及更改 2MB 的数据块。我们在 6 个集群成员中使用 271 个分片的默认分片配置。有 40 到 80 个客户。每个客户端连接都应该是长期稳定的。
“偶尔”我们会遇到这样一种情况，即提供集群的 Java 应用程序反复重启，而任何试图写入集群的客户端都无法这样做。由于 JVM 命令行的限制，我们过去遇到过集群应用 运行 内存不足的问题。我们之前已经增加了这些并且（据我所知）进程重启不再由 OutOfMemory 异常引起。
我知道我们运行正在使用一个非常旧的版本，许多人会建议简单地更新。这是我们将要开展的工作，但我们正在尝试诊断我们面前的系统存在的问题。
我在这里寻找的是关于要执行的调查类型的任何建议，对 运行 的查询（在系统健康时或在系统处于此故障状态时定期查询） .
在诊断此类问题时，我们经常使用 netstat、tcpdump、wireshark 和 top 等工具（我相信还有更多工具），但无法确定此问题的令人信服的根本原因。
非常感谢任何帮助。
谢谢，
戴夫
根据问题描述。
我们解决这个问题的唯一方法是完全反弹集群 - 即。停止所有成员，然后重新启动集群。
理想情况下，我们有一个系统可以保持稳定，并且可以从导致我们看到的问题的任何“事件”中恢复。
这可能涉及配置或代码更改。
更新大小为 2MB 的条目会产生许多后果 - 巨大的 serialization/deserialization 成本、网络中的胖数据包、在 JVM 堆中容纳这些块的成本等。理想的条目大小为 < 30-40KB。
对于您眼前的问题，请从 GC 诊断开始。您可以使用 jstat 来调查内存使用模式。如果您 运行 进入大量完整 GC and/or back-to-back 完整 GC，那么您将需要调整堆设置。还要检查网络带宽，这通常是胖数据包通过网络传输的主要嫌疑人。
以上所有只是 band-aid 解决方案，您真的应该将您的条目分解为更小的条目。
我们使用 Hazelcast 已经很多年了，但我是这个团队的新手。 我们有一个由专用 Java 应用程序组成的集群（它的唯一目的是提供集群）。它使用 3.8.2 jar 和 运行ning JDK 1.8.0_192 on Linux (Centos 7).
集群管理相对静态的数据（即一些更新day/week）。尽管更新可能涉及更改 2MB 的数据块。我们在 6 个集群成员中使用 271 个分片的默认分片配置。有 40 到 80 个客户。每个客户端连接都应该是长期稳定的。
“偶尔”我们会遇到这样一种情况，即提供集群的 Java 应用程序反复重启，而任何试图写入集群的客户端都无法这样做。由于 JVM 命令行的限制，我们过去遇到过集群应用 运行 内存不足的问题。我们之前已经增加了这些并且（据我所知）进程重启不再由 OutOfMemory 异常引起。
我知道我们运行正在使用一个非常旧的版本，许多人会建议简单地更新。这是我们将要开展的工作，但我们正在尝试诊断我们面前的系统存在的问题。
我在这里寻找的是关于要执行的调查类型的任何建议，对 运行 的查询（在系统健康时或在系统处于此故障状态时定期查询） .
在诊断此类问题时，我们经常使用 netstat、tcpdump、wireshark 和 top 等工具（我相信还有更多工具），但无法确定此问题的令人信服的根本原因。
非常感谢任何帮助。
谢谢， 戴夫
根据问题描述。 我们解决这个问题的唯一方法是完全反弹集群 - 即。停止所有成员，然后重新启动集群。 理想情况下，我们有一个系统可以保持稳定，并且可以从导致我们看到的问题的任何“事件”中恢复。 这可能涉及配置或代码更改。
更新大小为 2MB 的条目会产生许多后果 - 巨大的 serialization/deserialization 成本、网络中的胖数据包、在 JVM 堆中容纳这些块的成本等。理想的条目大小为 < 30-40KB。
对于您眼前的问题，请从 GC 诊断开始。您可以使用 jstat 来调查内存使用模式。如果您 运行 进入大量完整 GC and/or back-to-back 完整 GC，那么您将需要调整堆设置。还要检查网络带宽，这通常是胖数据包通过网络传输的主要嫌疑人。
以上所有只是 band-aid 解决方案，您真的应该将您的条目分解为更小的条目。