Hello,

I have been tracking this issue for a few weeks within an environment. And what I have been noticing is the performance of the UNIFYBroker service deteriorating over time. While there is an existing work around, it would be good to find the root cause of this, whether it be a poorly configured item somewhere or an underlying issue.

Currently in the environment we notice the service become slower, at a minimum, over the course of about a week. It will gradually take sets of operation lists longer and longer to run. More specifically this will be worse on Monday after all the Full Baseline operations run over the weekend. And then gradually get even worse from there. The only correlation I can see so far is during the times it is running slow, is the service will be using upward of 5GB of ram, even getting to over 10GB if left unattended for longer than a week. It will retain these high levels of memory usage even while no operations are running. The only way to resolve the issue, is to restart the service, which currently happens on a Monday every week.

The environment is quite large with a Broker instance that manages over 1 million entities. However the server (both local and DB) has the specifications to deal with the load. Please see these below. It is also worth noting here also that to eliminate concurrency issues, the scheduling is setup to run everything sequentially (i.e UNIFYNow will step through each operation one at a time and no two operations will run at the same time both in MIM and UNIFYBroker).

Broker Server Specs:

CPU: 16 cores

Memory: 32GB

DB Server Specs:

CPU: 12 cores

Memory: 48GB

Although I haven't gathered this information for previous weeks, I have noticed some strange occurrences this morning and have documented them below:

• Old LDAP Gateway connection that has not been closed:
• 
• Large number of SQL Connection to the UNIFYBroker DB:
• 
• High service memory usage while nothing is running (as mentioned before)
• 

I will attach the logs and additional information below. Also in the logs below I have included information on the DB connections both before and after recycle the LDAP Gateway. But also note that recycling the LDAP Gateway also had no effect on the memory usage of the service. Let me know if there was anything else I can do to assist.

UNIFYBroker: v5.3.1

Please see attached Broker configuration.  The "MIM LMS Group Users" connector generates records for groups, with a multivalued field "PersonNumbers" that is then used by the "MIM LMS Person" adapter in a Foreign Multivalued Group Transformation to generate the DNs of the groups each user is a member of.  When a group has no members, running an Import All on the connector causes a "Value cannot be null" error to be logged.  If I change the source data to not include any groups with no PersonNumbers data then the error does not occur

As a workaround, I've inserted a dummy value into blank PersonNumbers field values as shown here:

I tried to replicate this issue in a simpler Broker instance, but I could not sorry.

After changing the Required flag for a field in my PowerShell schema script, I re-ran Request Schema and the UI didn't show any fields as changed.  After I Merged Changes the field was not updated, and I had to update the Required flag manually.

It seems a reasonable expectation that a change of any field attribute should be flagged by the UI and applied when Merge is clicked.

I am trying to configure an export flow in MIM for a DN field in UNIFYBroker, and I see this error:

However, when I use LDP.exe to connect to UNIFYBroker via the LDAP gateway I can Add or Replace a DN value in that field successfully, so the limitation appears to be in the UNIFYBroker ECMA2 DLL rather than in UNIFYBroker itself.

Could you please advise if this is the expected behaviour?  If it is then could you comment on why the limitation exists and advise what we should do as a workaround?