如何解决部署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
关闭集群后,我们必须杀死所有服务器,因为服务器进程仍然存在,但再也无法正常工作了。因为在生产中,所以我们很着急。因此,我们执行了以下过程进行恢复。
- 定位器似乎仍在工作。但是我们使用gfsh逐一重新启动了定位器。
- 由于gfsh无法看到服务器。我们不得不杀死所有服务器的进程。
- 我们开始使用gfsh在服务器上。但是过程挂在:
[info ----- CST <main> tid=0x1] Initializing region PdxTypes
- 我们使用gfsh启动了另一台服务器,然后第一台服务器继续运行并开始从持久性存储中加载数据。
- 通过启动最后一个服务器来恢复备份。
任何人都可以就此事件提供建议吗?
我们怀疑jar部署会对该集群造成额外的负载,因此会有一些非常繁忙的事情,例如内存GC之类的。但是“卡滞”是异常的。我们怀疑jar文件不兼容问题。但是我们尝试在测试环境上尝试这样做,但是它部署jar(即使是稍微不兼容的jar)也不会导致服务器挂起。
向专家咨询!!!提前谢谢。
解决方法
我们必须为此jar文件计划维护时间。
当我们停止该服务器上的所有有效负载时,我们开始部署jar文件。
这一次,我们发现jvm GC的暂停时间超过20秒。
因此,我们意识到此问题是性能问题。我们需要调整jvm GC。
此事件的根源是部署jar文件会导致大量的GC负载。仅供参考。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。