Datahub启动失败,因为池大小超过了最大限制

2020-09-23 12:08发布

         点击此处--->   EasySAP.com群内免费提供SAP练习系统(在群公告中)

加入QQ群:457200227(SAP S4 HANA技术交流) 群内免费提供SAP练习系统(在群公告中)


大家好,最近我们遇到了以下问题-

2018-03-02 23:58:34,607 [错误] [chdaePoolEventHandler]无法启动数据中心java.lang.RuntimeException:要在池此处的池名中发布的项目数超过了限制 由datahub.init.publishable.items.query.limit属性提供的100000。 请以创建-拖放模式重新启动Data Hub并重新发送或以标准模式重新启动Data Hub并在此处池名触发池的发布。 在com.hybris.datahub.lifecycle.ReinitializeCanonicalCacheHandler.initializePool(ReinitializeCanonicalCacheHandler.java:60)〜[datahub-in-memory-6.6.0.0-RC4.jar:6.6.0.0-RC4]

当我们将datahub.init.publishable.items.query.limit的值修改为更大的值时,此问题得到解决。 先前它使用默认值'10000',但是在尝试分析根本原因时,注意到以下内容

  1. 大多数状态为"成功"的规范项都在CanonicalItem表中。 尽管启用了以下属性,但没有被删除。 datahub.cleanup.publisheditems.enabled = true

  2. 池中的项目数由多少组成? 它是该池中原始和规范项的总数吗? 因为我们使用IN_MEMORY配置模式,所以不会保留目标项目。

  3. 是否可以通过API检查池大小以进行监视? 一旦接近阈值,我们就可以手动删除已处理的原始和规范项目。 还有其他更好的解决方案来避免此问题吗? 请提出建议。

         点击此处--->   EasySAP.com群内免费提供SAP练习系统(在群公告中)

加入QQ群:457200227(SAP S4 HANA技术交流) 群内免费提供SAP练习系统(在群公告中)


大家好,最近我们遇到了以下问题-

2018-03-02 23:58:34,607 [错误] [chdaePoolEventHandler]无法启动数据中心java.lang.RuntimeException:要在池此处的池名中发布的项目数超过了限制 由datahub.init.publishable.items.query.limit属性提供的100000。 请以创建-拖放模式重新启动Data Hub并重新发送或以标准模式重新启动Data Hub并在此处池名触发池的发布。 在com.hybris.datahub.lifecycle.ReinitializeCanonicalCacheHandler.initializePool(ReinitializeCanonicalCacheHandler.java:60)〜[datahub-in-memory-6.6.0.0-RC4.jar:6.6.0.0-RC4]

当我们将datahub.init.publishable.items.query.limit的值修改为更大的值时,此问题得到解决。 先前它使用默认值'10000',但是在尝试分析根本原因时,注意到以下内容

  1. 大多数状态为"成功"的规范项都在CanonicalItem表中。 尽管启用了以下属性,但没有被删除。 datahub.cleanup.publisheditems.enabled = true

  2. 池中的项目数由多少组成? 它是该池中原始和规范项的总数吗? 因为我们使用IN_MEMORY配置模式,所以不会保留目标项目。

  3. 是否可以通过API检查池大小以进行监视? 一旦接近阈值,我们就可以手动删除已处理的原始和规范项目。 还有其他更好的解决方案来避免此问题吗? 请提出建议。

付费偷看设置
发送
11条回答
SAP小黑
1楼 · 2020-09-23 12:20.采纳回答

Kauser,

问题的根本原因是DataHub不执行发布。 他们应该在构图完成后立即就学了,但事实并非如此。 检查日志中可能提示您但配置错误的内容。 阅读动态出版物文档。 最有可能的 target.system.publication.configuration 属性不存在或不正确。 它应包含以下格式的值:

 <代码>  [, 

对于要将数据加载到的每个池,池与目标目标系统之间应有一个映射。 首先解决此问题以启用自动发布。

然后,没有简单的方法来解决发布缺失的结果,因此在考虑选项之前,让我回答您遇到的三个问题。

大多数状态为"成功"的规范项都在CanonicalItem表中。 尽管启用了以下属性,但没有被删除。 datahub.cleanup.publisheditems.enabled = true

即使清除扩展程序配置正确并正在运行,它也不会删除未发布的规范项。 它仅删除已经发布的项目。 因此,现在让我们忽略它-datahub-cleanup可能没有任何问题。 以下是一些选项:

池中的项目由多少组成? 它是该池中原始和规范项的总数吗? 因为我们使用IN_MEMORY配置模式,所以不会保留目标项目。

通常,池包含原始项目,规范项目和目标项目。 在IN_MEMORY模式下,这是真的-没有目标项目。 但是,在您看到的异常情况下,它只是规范项目,其状态为SUCCESS,在CanItemPubStatus表中没有相应的记录。 尝试发布后,该表中将有一个已发布规范项的记录。

是否可以通过API检查池大小以进行监视?

是的,有。 对于这种特定情况,可以使用/pools/{poolName}/status-counts/canonical 来检索您拥有多少规范项(计数按项状态划分)和/pools/{ poolName}/status-counts/canonical-publication 可用于检索已发布项目的计数(计数按发布状态划分)。 可以在 REST API 中找到更多详细信息。 这些数字也暴露在DataHub仪表板上的Backoffice内部。

现在,我想到了修复数据的选项:

  1. 如果可以将原始数据重新发送到DataHub,则来自异常的建议可能是最简单的。 将autoInitMode更改为create-drop,重新启动Data并再次开始发送数据。 在发送数据时,项目应发布,问题已解决。

  2. 再次增强了 datahub.init.publishable.items.query.limit 属性。 但是,显然有超过10万个未发布的规范项目,因此这可能导致:

    • 内存不足异常

    • 表现很差

    • 由于数据量大和性能差,还有一些其他意外错误。

  3. 在数据库中执行手动操作。 固定DataHub时,请确保没有新数据进入并且没有运行合成:

    • 进行数据库备份。

    • 确保CanonicalItem中没有状态为ARCHIVED的项目(否则让datahub-cleanup删除它们或手动删除它们)

    • 将CanonicalItem中的项目状态更改为ARCHIVED(可能是1万个左右的项目除外)。

    • 重新启动DataHub。 它应尝试发布状态为SUCCESS的剩余10000件商品。

    • 将另一部分规范项从"已归档"状态更新为"成功",然后再次重新启动DataHub。

    • 继续这样做,直到所有项目都发布为止。

蓋茨
2楼-- · 2020-09-23 12:19

除了手动清洁之外,您能否提出更好的解决方案?

三十六小时_GS
3楼-- · 2020-09-23 12:40

由于这是生产中的问题,我们无法获取所有原始数据,因此我们增加了属性'datahub.init.publishable.items.query.limit'的值,并 Datahub服务器启动正常。 关于属性" target.system.publication.configuration",已正确配置。 它已经投入生产了一年多,并且运行良好。 以下是发布和排版延迟设置

  • sapcoreconfiguration.autocompose.sleeptime = 3000 sapcoreconfiguration.autopublish.sleeptime = 30000 sapcoreconfiguration.autopublish.initialsleeptime = 1500

但是,这是我们看到的规范项堆积的唯一池。 即使到了今天,成功状态下的规范项目数量仍在增加。 无论如何,是否需要从日志中进行验证? 作为替代方案,如果我们必须在监视时手动删除规范对象,可以避免删除以下内容,以免超出池大小,这是安全的:-

  1. 所有已归档的规范项目

  2. 具有在CanonicalItemPubStatus中具有相应记录且状态为"成功"的所有成功状态的所有规范项(因为CanonicalItemPubStatus中的" success"状态表示此发布已成功)?

骆驼绵羊
4楼-- · 2020-09-23 12:28

最简单的方法是将autoInitMode更改为create-drop并重新启动DataHub。 那就是如果您有能力丢失所有数据。 否则,如果没有手动操作,我看不到解决方案,但也许其他一些专家可以提供一些建议。

三十六小时_GS
5楼-- · 2020-09-23 12:20

运行清理时,您应该会看到类似以下内容的

  [INFO] [com.hybris.datahub.cleanup.jdbc.AbstractJdbcCleanupService]成功发布的项目清理:[从`CanonicalItem` WHERE`id` IN(:ids)中删除]:x记录已删除
  [INFO] [com.hybris.datahub.cleanup.jdbc.AbstractJdbcCleanupService]成功发布的项目清理:[从`PublicationError`中删除`canonicalitempublicationstatus` IN(:secondaryids)]:x记录已删除
  [INFO] [com.hybris.datahub.cleanup.jdbc.AbstractJdbcCleanupService]成功发布的项目清理:[从`CanItemPubStatus`中的`id` IN(:secondaryids)中删除]:删除了x条记录
  

但是,正如我之前所说,该池中没有要删除的清理内容。 该池会累积未发布的项目,而清理只会删除已经发布的项目。

通过将POST发送到/pools/{poolName}/publications,尝试手动启动该池中的发布。 该主体应包含要发布的目标系统。 例如, {" targetSystemPublications":[{" targetSystemName":" name_of_the_target_system"}]} 。 可以从该池的 target.system.publication.configuration 属性的值中获取 name_of_the_target_system

您可以对同一URL使用GET请求来检查发布状态。 请参阅REST API以跟踪详细信息。 此外,日志中还将打印出信息。

clever101
6楼-- · 2020-09-23 12:39

是否已启用发布重试(" datahub.max.publication.retry.count"> 0)? 另外,请检查PublicationRetry表是否为空。 出版物重试应管理出版物状态。 如果禁用了重试并且发布状态不断累积,则可能是清除扩展中的错误。 但是无论如何,我最关心的是为什么会有这么多的发布错误? 建模问题,依赖问题,配置问题?

jovirus
7楼-- · 2020-09-23 12:18


经过进一步分析,发现在每次重试尝试期间,发布失败的失败的规范项正在CanItemPubStatus中创建一个条目。 目前,我们将重试间隔设置为24小时。 尽管此表的大小正在增加。 这可能是由于解决发布失败错误的延迟,因此后续发布也失败了。 但是,清理或保留cronjob不会清除此重复数据。 这意味着如果规范项被发布1000次,则此表中将有1000条记录。 我可能的解决办法是清除数据-编写cron作业以删除重复的条目,并且CanItemPubStatus表中每个失败的规范项只有一个条目。 还有其他想法吗?

一周热门 更多>