FAQ

FAQ: IDM/OpenIDM performance and tuning

Last updated Jun 26, 2019

The purpose of this FAQ is to provide answers to commonly asked questions regarding performance and tuning for IDM/OpenIDM.


Frequently asked questions

Q. Are there any recommendations for sizing IDM/OpenIDM servers?

A. No, the performance of IDM/OpenIDM depends entirely on your specific environment and the exact nature of scripted customizations. To establish appropriate sizing, you will need to perform adequate benchmark testing. 

See Release Notes › Fulfilling Memory Requirements for further information.

Note

Sizing and/or tuning recommendations are outside the scope of ForgeRock support; if you want more tailored advice, consider engaging Deployment Support Services.

Q. Is there any best practice advice for benchmark testing?

A. ForgeRock recommends the following:

  • Maintain a staging environment that matches production where you can simulate the load you will have in production. This allows you to resolve any issues you identify in a non-production environment.
  • Establish a simple benchmark prior to adding external resources; you can then incrementally add resources and processes to establish what impact each one has.

Q. What is the recommended Java Virtual Machines (JVM) heap size for IDM/OpenIDM?

A. There are no definitive rules for the size of JVM heap size required as it will vary across individual environments and applications, but you should refer to Best practice for JVM Tuning for best practice advice. Additionally, ensure you configure JVM garbage collection appropriately as GC times can increase with large heap sizes causing significant impacts to application performance and CPU utilization. See How do I change the JVM heap size for IDM/OpenIDM (All versions)? for further information.

You can monitor JVM memory usage using one of the health endpoints as detailed in Integrator's Guide › Memory Health Check.

Note

For a 32-bit JVM or a 32-bit operating system, the limit for the process size is 4GB, that is, 2^32; this cannot be exceeded regardless of the amount of heap space allocated.

Q. How can I troubleshoot performance issues?

A. If you have no benchmark tests for comparison and encounter performance issues, the recommendation is to reduce your system to the bare minimum and then incrementally add back resources and processes in order to identify which one is causing the bottleneck.

The following tips should also help:

Q. How can I improve reconciliation performance?

A. Firstly, you should identify reconciliation performance issues per the advice in How do I identify reconciliation performance issues in IDM/OpenIDM (All versions)?; this article also offers tuning advice. In addition to this, you can:

Q. Are there any recommendations for sizing the database needed for the IDM/OpenIDM repository?

A. Database sizing for the IDM/OpenIDM repository depends on various factors such as the number of managed objects (users, groups, roles etc), relationships, links, audit logs, configurations, workflow, reconciliations etc. Since all these factors vary from one deployment to another, it is not possible to give specific recommendations. However, the following guidelines should help when estimating the size of database required: 

Managed objects

You can calculate the size of your IDM/OpenIDM deployment by first calculating the size of your database for sample data (such as 20 users) and then multiplying that by the expected number of users. The following tables typically grow as more managed objects are added: 

  • managedobjects - one entry per managed object. 
  • managedobjectproperties - N entries per managed object, where N is the number of indexed / searchable properties: Integrator's Guide › Creating and Modifying Managed Object Types.
  • links - the total number of links is less than or equal to the number of managed objects multiplied by the number of unique mappings. For example, if you have 20 managed users and 3 mappings (systemLdapAccounts_managedUser, managedUser_systemLdapAccounts and systemADAccount_managedUser), the total number of links would be less than or equal to 40 (20 * 2). The systemLdapAccounts_managedUser and managedUser_systemLdapAccounts mappings are bidirectional syncs and may use the same links: Integrator's Guide › Mapping Source Objects to Target Objects.
  • relationships, relationshipproperties - relationships are especially sensitive to growth when searchablebydefault is set to true (the various repo.jdbc.json files provided in the /path/to/idm/db directory have different defaults so you may end up generating more of this data that you need or expect). Additionally, roles utilize the relationships table as of OpenIDM 4. 
  • Activiti - these tables can grow over time as running workflows result in persisting data in these tables. 

Most of the other tables such as configobjects, internaluser etc are static once you have a working IDM/OpenIDM configuration and should not have much impact on database sizing.

Audit logs

Audit logs can have a huge impact on database sizing and disk space. By default, IDM/OpenIDM stores audit logs in both CSV files and in the database. The size of audit logs depends on IDM/OpenIDM usage. There are different types of audit logs and their corresponding events: Integrator's Guide › Audit Event Topics. The following tables in particular grow with each reconciliation:

  • recon/audit - this table reports the status for each user and grows by one entry for each source record. Additionally, a further entry is created for each target record that is not linked or correlated (CONFIRMED, FOUND). The size of a single reconciliation report depends on the data size of source and target; the overall data requirement depends on how many reports you keep. You can reduce the size of the recon/audit table for actions you're not interested in by setting the action to NOREPORT.
  • recon/activity - this table reports all activity and grows by one entry for each modifying action regardless of the source of the action, for example, reconciliation, synchronization etc. The overall size depends on how many changes are processed and how long these records are kept.

The following best practices should be heeded:

Q. How can I manage the QueuedThreadPool in Jetty?

A. You can change the Jetty thread pool settings by updating the config.properties file (located in the /path/to/idm/conf directory) or by setting the OPENIDM_OPTS environment variable when you start IDM/OpenIDM. See Integrator's Guide › Adjusting Jetty Thread Settings for further information.

See Also

How do I enable Garbage Collector (GC) Logging for IDM/OpenIDM (All versions)?

How do I collect data for troubleshooting high CPU utilization on IDM/OpenIDM (All versions) servers?

Performance tuning and monitoring ForgeRock products

Integrator's Guide › Monitoring Basic Server Health

Integrator's Guide › Optimizing Reconciliation Performance

Related Training

N/A



Copyright and TrademarksCopyright © 2019 ForgeRock, all rights reserved.
Loading...