Hazelcast分布式map get操作的延迟极高

我们在项目中使用分布式Hazelcast映射，最近遇到了一个具有极高get延迟的问题。我们使用了

IMap.get（…）

调用，在某些情况下需要几个小时才能完成。在这次事件之后，我们切换到带有超时的

IMap.getAsync（…）

API，这为我们解决了问题，但我很好奇是否有人有类似的问题

我们的Hazelcast版本是3.9.0。在事件期间，我们将

hazelcast.operation.call.timeout.millis设置为5000，并将
async backup count=“3”
设置为
read backup data=“true”
。由于不相关的后台处理，我们在一些主机上也出现了零星的CPU使用高峰（几分钟内高达100%），这可能会影响Hazelcast

我们在日志中发现的唯一可疑之处是，在事件发生前后，所有主机都在抱怨某个主机，如下所示：

Oct 24, 2018 3:53:01 PM com.hazelcast.spi.impl.operationservice.impl.InboundResponseHandler
WARNING: [hostX]:5702 [dev] [3.9] No Invocation found for call timeout response with callId739863 sent from [hostY]:5702
Oct 24, 2018 3:53:01 PM com.hazelcast.spi.impl.operationservice.impl.InboundResponseHandler
WARNING: [hostX]:5702 [dev] [3.9] No Invocation found for call timeout response with callId739864 sent from [hostY]:5702
Oct 24, 2018 3:53:01 PM com.hazelcast.spi.impl.operationservice.impl.InboundResponseHandler
WARNING: [hostX]:5702 [dev] [3.9] No Invocation found for call timeout response with callId739852 sent from [hostY]:5702
Oct 24, 2018 3:53:01 PM com.hazelcast.spi.impl.operationservice.impl.InboundResponseHandler
WARNING: [hostX]:5702 [dev] [3.9] No Invocation found for call timeout response with callId739870 sent from [hostY]:5702
Oct 24, 2018 3:53:01 PM com.hazelcast.spi.impl.operationservice.impl.InboundResponseHandler
WARNING: [hostX]:5702 [dev] [3.9] No Invocation found for call timeout response with callId739874 sent from [hostY]:5702
Oct 24, 2018 3:53:01 PM com.hazelcast.spi.impl.operationservice.impl.InboundResponseHandler

在主机的日志中：

Oct 24, 2018 3:53:01 PM com.hazelcast.spi.impl.operationservice.impl.InvocationMonitor
WARNING: [hostY]:5702 [dev] [3.9] MonitorInvocationsTask delayed 14294 ms
Oct 24, 2018 3:53:01 PM com.hazelcast.spi.impl.operationservice.impl.InvocationMonitor
WARNING: [hostY]:5702 [dev] [3.9] BroadcastOperationControlTask delayed 13544 ms

有什么想法吗？
从
hostY
的日志来看，hostY似乎受到GC暂停的影响
MonitorInvocationsTask
计划每秒钟运行一次，但它表示其执行延迟了14秒。由于您的配置（
hazelcast.operation.call.timeout.millis/4=1250 ms
），应该几乎每秒都安排一次
BroadcastOperationControlTask
），但它同样会延迟13秒

您可以通过启用GC日志来验证这一点。此外，当内存和/或CPU使用率超过某个阈值时，Hazelcast应定期打印
HealthMonitor
日志。
当您具有高延迟和CPU峰值时，是否可以共享Hazelcast群集成员日志？当时我们没有详细的Hazelcast诊断日志。我用我们注意到的可疑日志更新了这个问题。这很有意义，谢谢。我们确实在事件发生前后的所有主机上都有
HealthMonitor
日志，它们大约每30秒打印一次。我们发现了一个类似的添加/删除呼叫报告问题-。这是相关的还是完全不同的？看起来像是客户端问题，已在3.9.1中修复。但根据您的日志，集群中的成员正遭受暂停。如果您查看健康监视器日志，您应该会看到内存使用情况和次要/主要GC暂停。