Richard，这里可能发生了一些事情，但是是的，更多的条目确实意味着更多的处理时间：）

首先，硬件/网络规格是否相同？ （更不用说Java和NW规范了）

每个系统构建了多少个调度程序？ 它们在哪里？

您是否正在处理完全相同的数据（要更新的条目和属性的数量）

所有这些都可能对 some 产生影响 在监视方面，我认为您应该做一些认真的数据库工作，并添加一些日志记录以查看正在发生的情况。

这些链接主要来自IDM 7，但我认为它们仍然占主导地位：
https://blogs.sap.com/2015/07/13/performance-tips-and-tricks-when-beginning-the-idm-journey/

https：//blogs.sap.com/2016/03/25/sap-identity-management-provisioning-monitor-tool/

https://apps.support.sap.com/sap/support/knowledge/preview/zh/2437631

https://apps.support.sap.com/sap/support/knowledge/preview/ zh/2456633

https://blogs.sap.com/2014/02/05/on-queue-processing-or-the-lack-thereof/

嗨，马特，

感谢您 输入。 一次小更新。.我注意到更新作业中的传递"处理来自后端的已删除配置文件分配"和"处理来自后端的已删除角色分配"无法正常工作。 这些是RDS的1：1副本。 但是，在我的情况下，他们正在删除IDM中的分配（而不是在后端），并且在下一次运行时，分配又被写回并再次被删除……很奇怪。 作为测试，我禁用了两次通过，结果将运行时间减少到将近半小时。 因此，我将对这些通行证进行更详细的研究。

Richard

Richard，

老实说，我从来没有 一直是RDS的粉丝。 是的，您可以尝试使用标准配置框架中的某些内容吗？

Matt

是的，在某些地方它是某种"测试版软件"。 我认为这是一个很好的起点。

我创建了自己的逻辑，现在运行时更好。 另外，我降低了调度程序的日志级别。 有很多脚本会用信息日志条目充斥整个系统，从而导致运行时间增加...对于某些进程> _ <