Java heap size for CA Identity Manager running on Websphere

[Shivam Mukhi]

Hi All,

We have CA Identity Manager 14.2 running on IBM WebSphere 8.5.5.11. I have two queries regarding JVM heap size.

• What are the possible causes in IDM for Java heap size to increase.
• What is the way to calculate the optimum heap size value based on specific environment.

Thanks in advance,
Shivam

[Bill Patton]

This is a tough question to answer for identity manger.

Here is what we know:
Compiled classes (actual IM Code) usually stored in the amount set aside by the maxPermGen setting.

Then for each data source you need to create the initial connections for a database connection pool and connection pools get loaded into JVM.
There are:
6 data source connection pools
    Object store
    TP store
    Archive
    Audit
    Report
    Workflow (optional but turned on by default)
 Additional if you left the example datasources in the configuration.
   
2 LDAP connection pools,
    Corp Store
    Prov Store (optional)

1 Jaim connection pool.
    Optional depending on the usage of Provisioning connection above.

Each connection pool is going to have a min and max, and at the start of the app server will load connections starting at the min and create new connections as needed until you reach the max settings.

All of these are stored in the JVM heap.

Then after this you will load the IME or IMEs into JVM cache.

Now unlike with CA directory where we say you need the same amount of ram available as the flat file that is storing data size because everything that is stored in the CA directory flat file is loaded into ram. Also unlike GovernanceMinder where we publish Ram needed for user attestation tied to the amount of roles and permissions.

IM simply does not know how many:
  Access roles you will have (only available if SM is integrated)
  Provisioning Roles you will have (not directly correlated to the amount of account templates you will have)
  Admin roles you will have (Also not directory correlated to the amount of admin tasks you will have) 

  and all of these get loaded and stored in JVM, Access roles, Provisioning Roles and Secondary attributes (account templates), Admin roles and tasks are all built into IM cache. 

Now take that we do not know each customer's need for custom classes that will be complied and loaded, then the through put and user turn over (password resets, user created and disables) so we cannot specify how many datasource connections each customer will have for each of the data sources and add that with some customers use Provisioning and some do not, finally add that we do not know how many custom admin roles point to custom admin tasks that customers will configure, and you should get a pretty good picture as to why Broadcom cannot provide a documented path to calculate the optimum heap size value based on specific environment.

You can also read more about this in:
https://ca-broadcom.wolkenservicedesk.com/external/article?articleId=46523

Possible causes for IDM for Java heap size to increase.
   For every task that you perform in IM, you need to go through task persistence.
   Meaning that if you kick of an explore/correlate of an endpoint and IMAG has the provisioning option turned on, then you will see a spike in the connection to the TP database, as well as the connection pool utilization for the 2 LDAP stores and the jiam connections. if the server was loaded with the min of 5(default for a connection pool) and had to build the remaining 15 (max of 20 is default) you will see two thing occur: Performance degradation as the connections are built in the connection pool and JVM spiking as those connections are being created and stored in JVM.

All of this is true for all application servers, not just WebSphere

Bill Patton