部署jar文件时，Apache Geode停止运行

问题描述

我们有一个带有4个定位器和3个服务器的Apache Geode集群。当我们将新版本的jar文件部署到该Goede集群时。定位器检测到超时，并因为将每个服务器和定位器从分发系统中删除而关闭了群集。

有我们怀疑问题根源的日志。

[warn 2020/10/10 17:04:05.989 CST <ThreadsMonitor> tid=0x11] Thread 2129 (0x851) is stuck

[warn 2020/10/10 17:04:05.993 CST <ThreadsMonitor> tid=0x11] Thread <2129> (0x851) that was executed at <10 Oct 2020 17:02:53 CST> has been stuck for <72.253 seconds> and number of thread monitor iteration <1>
Thread Name <Function Execution Processor119> state <BLOCKED>
Waiting on <java.lang.Class@48cd319d>
Owned By <Removing shunned GemFire node 172.18.13.13(server_13.13:27524)<v24>:41001> with ID <2285>
Executor Group <FunctionExecutionPooledExecutor>
Monitored metric <ResourceManagerStats.numThreadsStuck>
Thread stack:
org.apache.geode.internal.cache.CacheFactoryStatics.getAnyInstance(CacheFactoryStatics.java:85)
org.apache.geode.cache.CacheFactory.getAnyInstance(CacheFactory.java:396)
org.apache.geode.internal.DeployedJar.cleanUp(DeployedJar.java:233)
org.apache.geode.internal.JarDeployer.registerNewVersions(JarDeployer.java:377)
org.apache.geode.internal.JarDeployer.deploy(JarDeployer.java:414)
org.apache.geode.management.internal.cli.functions.DeployFunction.execute(DeployFunction.java:79)
org.apache.geode.internal.cache.MemberFunctionStreamingMessage.process(MemberFunctionStreamingMessage.java:201)
org.apache.geode.distributed.internal.DistributionMessage.scheduleAction(DistributionMessage.java:372)
org.apache.geode.distributed.internal.DistributionMessage$1.run(DistributionMessage.java:436)
java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
org.apache.geode.distributed.internal.ClusterOperationExecutors.runUntilShutdown(ClusterOperationExecutors.java:475)
org.apache.geode.distributed.internal.ClusterOperationExecutors.doFunctionExecutionThread(ClusterOperationExecutors.java:393)
org.apache.geode.distributed.internal.ClusterOperationExecutors$$Lambda$72/738636051.invoke(Unknown Source)
org.apache.geode.logging.internal.executors.LoggingThreadFactory.lambda$newThread$0(LoggingThreadFactory.java:119)
org.apache.geode.logging.internal.executors.LoggingThreadFactory$$Lambda$62/1490297742.run(Unknown Source)
java.lang.Thread.run(Thread.java:748)
Lock owner thread stack
java.util.Timer.purge(Timer.java:462)
org.apache.geode.internal.SystemTimer.timerPurge(SystemTimer.java:287)
org.apache.geode.internal.cache.ExpirationScheduler.forcePurge(ExpirationScheduler.java:46)
org.apache.geode.internal.cache.LocalRegion.cancelAllEntryExpiryTasks(LocalRegion.java:7937)
org.apache.geode.internal.cache.LocalRegion.recursiveDestroyRegion(LocalRegion.java:2592)
org.apache.geode.internal.cache.LocalRegion.basicDestroyRegion(LocalRegion.java:6177)
org.apache.geode.internal.cache.DistributedRegion.basicDestroyRegion(DistributedRegion.java:1822)
org.apache.geode.internal.cache.LocalRegion.handleCacheClose(LocalRegion.java:7249)
org.apache.geode.internal.cache.DistributedRegion.handleCacheClose(DistributedRegion.java:2676)
org.apache.geode.internal.cache.GemFireCacheImpl.close(GemFireCacheImpl.java:2205)
org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1550)
org.apache.geode.distributed.internal.InternalDistributedSystem.reconnect(InternalDistributedSystem.java:2545)
org.apache.geode.distributed.internal.InternalDistributedSystem.tryReconnect(InternalDistributedSystem.java:2408)
org.apache.geode.distributed.internal.InternalDistributedSystem.disconnect(InternalDistributedSystem.java:1247)
org.apache.geode.distributed.internal.ClusterDistributionManager$DMListener.membershipFailure(ClusterDistributionManager.java:2303)
org.apache.geode.distributed.internal.membership.adapter.GMSMembershipManager.requestMemberRemoval(GMSMembershipManager.java:1507)
org.apache.geode.distributed.internal.membership.adapter.GMSMembershipManager.lambda$addSurpriseMember$1(GMSMembershipManager.java:875)
org.apache.geode.distributed.internal.membership.adapter.GMSMembershipManager$$Lambda$366/738075788.run(Unknown Source)
java.lang.Thread.run(Thread.java:748)


[warn 2020/10/10 17:04:05.993 CST <ThreadsMonitor> tid=0x11] There is 1 stuck thread in this node

关闭集群后，我们必须杀死所有服务器，因为服务器进程仍然存在，但再也无法正常工作了。因为在生产中，所以我们很着急。因此，我们执行了以下过程进行恢复。

1. 定位器似乎仍在工作。但是我们使用gfsh逐一重新启动了定位器。
2. 由于gfsh无法看到服务器。我们不得不杀死所有服务器的进程。
3. 我们开始使用gfsh在服务器上。但是过程挂在： [info ----- CST <main> tid=0x1] Initializing region PdxTypes
4. 我们使用gfsh启动了另一台服务器，然后第一台服务器继续运行并开始从持久性存储中加载数据。
5. 通过启动最后一个服务器来恢复备份。

任何人都可以就此事件提供建议吗？

我们怀疑jar部署会对该集群造成额外的负载，因此会有一些非常繁忙的事情，例如内存GC之类的。但是“卡滞”是异常的。我们怀疑jar文件不兼容问题。但是我们尝试在测试环境上尝试这样做，但是它部署jar（即使是稍微不兼容的jar）也不会导致服务器挂起。

向专家咨询！！！提前谢谢。

解决方法

我们必须为此jar文件计划维护时间。

当我们停止该服务器上的所有有效负载时，我们开始部署jar文件。

这一次，我们发现jvm GC的暂停时间超过20秒。

因此，我们意识到此问题是性能问题。我们需要调整jvm GC。

此事件的根源是部署jar文件会导致大量的GC负载。仅供参考。