Hybris：是什么导致了几个后台长时间操作项目，这些项目似乎导致了性能问题？

海布里斯：1905.14

我在CCV2中托管的Hybris实例上遇到性能问题。它正在减缓店面和后台的速度。如果我转到HAC>监视>挂起，我会看到几个后台长操作项。线程转储还显示与backoffice相关的几个线程

没有正在运行的cronjobs，触发器已设置为active=false。一段时间后，服务器需要重新启动，因为backoffice不再加载。最后，服务器无法初始化，因为它包含数据

backoffice中只有很少的配置，只是一些XML配置来定制不同用户组的树视图

我无法在本地服务器上复制性能问题。您知道是什么原因导致这些后台长期操作项目吗

被阻止的线程如下所示：

priority:5 - threadId:0x2095 - nativeId:0x82f - nativeId (decimal):2095 - state:BLOCKED
stackTrace:
java.lang.Thread.State: BLOCKED
at java.base@11.0.6/java.util.Collections$SynchronizedMap.put(Collections.java:2598)
- waiting to lock java.util.Collections$SynchronizedMap@1e60f80f
at com.hybris.cockpitng.util.cache.WidgetAsyncWarmUpCache$WarmUpOperation.lambda$execute$0(WidgetAsyncWarmUpCache.java:122)
at com.hybris.cockpitng.util.cache.WidgetAsyncWarmUpCache$WarmUpOperation$$Lambda$1481/0x00000008020d4c40.accept(Unknown Source)
at java.base@11.0.6/java.util.ArrayList.forEach(ArrayList.java:1540)
at com.hybris.cockpitng.util.cache.WidgetAsyncWarmUpCache$WarmUpOperation.execute(WidgetAsyncWarmUpCache.java:122)
at com.hybris.cockpitng.engine.impl.DefaultWidgetInstanceManager.lambda$prepareLongOperation$2(DefaultWidgetInstanceManager.java:223)
at com.hybris.cockpitng.engine.impl.DefaultWidgetInstanceManager$$Lambda$1466/0x00000008020d0040.get(Unknown Source)
at com.hybris.cockpitng.engine.operations.CockpitNGBackgroundOperation.runInternal(CockpitNGBackgroundOperation.java:125)
at com.hybris.cockpitng.engine.operations.CockpitNGBackgroundOperation.run(CockpitNGBackgroundOperation.java:93)
at com.hybris.backoffice.cockpitng.util.BackofficeThreadContextCreator$RunnableWithParentThreadContext.run(BackofficeThreadContextCreator.java:100)
at java.base@11.0.6/java.lang.Thread.run(Thread.java:834)
at de.hybris.platform.core.threadregistry.RegistrableThread.internalRun(RegistrableThread.java:141)
at de.hybris.platform.core.threadregistry.RegistrableThread.run(RegistrableThread.java:131)
Locked synchronizers: count = 0

fastthread.io中的线程计数：

我过去也遇到过类似的情况（据我记忆，我的线程转储与您的线程转储完全相同，），问题是由一个变体引起的，该变体本身就是一个基本产品。因此，在触发同步或索引时，会出现大量堆栈溢出错误，因为代码试图同时同步/索引将自身作为baseProduct的基本产品，使其达到无穷远

为了检查您是否有类似的情况，您可以运行以下灵活的搜索：

select {VP:code} from {VariantProduct as VP} where {VP:baseProduct}={VP:pk}

---

PS：我检查了，问题仍然在Hybris 1905.11上重现（Hybris仍然允许您创建此循环依赖项）

更新5/27 15:29:Hybris确认它是1905.14中的一个错误：。CCV2的解决方案在JIRA tiket中：

将附加的cockpitframework-19.05.14-RC4.jar上传到您的存储库中 root/CUSTOMIZE/modules/backoffice framework/backoffice/web/webroot/web-INF/lib

建造

部署

然而，我们现在选择使用1905.13

xxx

作为一项临时决议（消除了性能问题），我们：

• 将Hybris 1905.14评级下调至1905.13
• 已删除/禁用热文件夹扩展

目前，我们无法确定问题是由于Hybris版本还是由于hotfolder扩展

---

我们有另一台服务器运行在Hybris 1905.14上，启用了hotfolders，它没有“后台长时间操作”问题。因此，此时，我们正在等待SAP提供一些响应（或问题调查）。

您是否尝试过分析线程转储？您可以从hac->Monitoring->Thread Dump生成一个。也许你可以在线程转储中看到为什么那些线程blocked@dj_frunza我已经用一个阻塞线程的示例更新了这个问题。这种情况在我们的案例中不会发生。VariantProductValidateInterceptor将抛出错误：建议的基本产品GenericVariantProductModel(8796094005249@17)没有变体类型-不能是基本产品是的，我相信你是对的。在我的例子中，客户的某个人还错误地在变体产品上设置了变体类型，并创建了此循环依赖项如果在导入/创建过程中停用了验证，则可能出现这种情况。无论如何，这仍然是未来需要注意的好信息。感谢分享您的经验/想法。：）谢谢你的发帖，这对我们帮助很大。@pratikabu你试过1905.16了吗？这个问题应该已经解决了。我们在生产部署日认真监控了CPU利用率。所以我们必须想出一些解决办法。但是我们会考虑迁移到新的补丁。