Hybris：是什么导致了多个 Backoffice Long Operation 项，这些项似乎导致了性能问题？

Question

混合动力车：1905.14

我在 CCV2 中托管的 Hybris 实例上遇到性能问题。它正在减慢店面和后台的速度。如果我转到 HAC > 监控 > 暂停，我会看到几个 Backoffice Long Operation 项目。线程转储还显示了几个与后台相关的线程。

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

后台配置最少，只是一些XML配置来自定义不同用户组的树视图。

我无法在本地复制性能问题。有什么想法可能导致这些 Backoffice Long Operation 项目吗？

阻塞的线程看起来像这样：

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[=10=](WidgetAsyncWarmUpCache.java:122)
at com.hybris.cockpitng.util.cache.WidgetAsyncWarmUpCache$WarmUpOperation$$Lambda81/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(DefaultWidgetInstanceManager.java:223)
at com.hybris.cockpitng.engine.impl.DefaultWidgetInstanceManager$$Lambda66/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 的线程数：

Answer 1

我过去有过类似的情况（据我所知，我的线程转储与你的相同），问题是由于一个变体引起的，该变体将自己作为基础产品。因此，当同步或索引被触发时，出现了很多 Whosebug 错误，因为代码还试图 synch/index 本身作为 baseProduct 的基础产品到无穷远。

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

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

PS：我检查过，问题仍然在 Hybris 1905.11

上重现（Hybris 仍然允许您创建这种循环依赖）

Answer 2

更新 5/27 15:29：Hybris 在 1905.14 中确认这是一个错误：ECP-5030 WidgetAsyncWarmUpCache causing CPU saturation with certain category structure。 CCV2 的解决方法在 JIRA tiket 中：

Upload attached cockpitframework-19.05.14-RC4.jar to your repository under root/CUSTOMIZE/modules/backoffice-framework/backoffice/web/webroot/WEB-INF/lib

Build

Deploy

不过，我们暂时选择使用 1905.13。

xxx

作为临时解决方案（消除了性能问题），我们有：

将 Hybris 1905.14 降级为 1905.13
Removed/Disabled 热文件夹扩展

目前，我们不能说问题是由于 Hybris 版本还是由于 hotfolder 扩展。

我们有另一台服务器运行在 Hybris 1905.14 上启用了热文件夹，它没有 "Backoffice Long Operation" 问题。所以，目前，我们只是在等待 SAP 提供一些响应（或对问题的调查）。

Hybris：是什么导致了多个 Backoffice Long Operation 项，这些项似乎导致了性能问题？

Hybris: What causes several Backoffice Long Operation items, which seems to be causing performance issues?

hybris