IdentityManager performance considerations and settings
Article ID: 46523
Updated On:
Products
Issue/Introduction
Introduction:
In regards to Identity Manager there are four major components that can negatively impact performance:
JVM Memory, Connection pooling, Task Persistence Cleanup, and Missing Database Indexes.
Since each client's architecture and processing requirements are unique CA Support can provide only general concepts for ensuring improved performance. For site-specifc performance evaluation and tuning please contact your CA Account Manager to arrange a health check, system sizing, or performance review.
Please understand that this information does not supersede the information in the IdentityManager documentation there is a chapter that talks about this at a high level but also talks about RBAC architecture and how that impacts performance.
Environment:
This information can be used with all application servers and all databases because the settings that we are talking about are configuration for the JVM, datasources, and how information is accessed from a database.
Environment
Component:
Resolution
Instructions:
JVM Memory:
Improperly tuned JVM memory causes GC errors and not enough connections to be created in a connection pool. A good rule of thumb is to look at the OS see what is required for Ram, then out of what is left give half to JVM. If you have 16 gigs and your OS needs 6, then you have 10 gigs left to work with. There are three settings: Xms Xmx and MaxPermSize Xms should be 1/3 to 1/2 the Max ram, MaxPermSize should be half of that. In this example you would have:
Xms=2gig Xmx=5gig MaxPermSize=1gig
This means that when the server starts, it will start with 2gig, and utilize up to 5 gig, when Garbage collection happens, it will clean up the difference between Xmx-(Xms+MaxPermSize) in this example 5gig-(2gig+1gig)=2gig.
https://docs.oracle.com/javase/8/docs/technotes/guides/troubleshoot/memleaks002.html
Notes on memory errors.
If you have more than one application running on the IM server, then these numbers will not work for you.
Connection pooling:
How is the above memory utilized? Besides loading the application into cache, you pre load connections for your connection pools. Every time an Application server has to create a connection, it is the most expensive performance related task that it can do. We want to load as many connections at server startup as needed so that users using the app do not have to wait for a connection to load. IM is run on an application server, and the JCS is run on an application server. For every connection made it uses JVM memory so we must monitor Garbage collection and out of memory errors.
At the IM application server level:
<datasource enabled="true" jndi-name="java:/iam/im/jdbc/jdbc/objectstore"
<pool>
<min-pool-size>5</min-pool-size>
<max-pool-size>20</max-pool-size>
</pool>
<datasource jndi-name="java:/iam/im/jdbc/jdbc/idm"
<pool>
<min-pool-size>5</min-pool-size>
<max-pool-size>20</max-pool-size>
</pool>
<datasource jndi-name="java:/iam/im/jdbc/jdbc/archive"
<pool>
<min-pool-size>5</min-pool-size>
<max-pool-size>20</max-pool-size>
</pool>
<datasource jndi-name="java:/iam/im/jdbc/auditDbDataSource"
<pool>
<min-pool-size>5</min-pool-size>
<max-pool-size>20</max-pool-size>
</pool>
<datasource jndi-name="java:/iam/im/jdbc/jdbc/reportsnapshot"
<pool>
<min-pool-size>5</min-pool-size>
<max-pool-size>20</max-pool-size>
</pool>
<datasource jndi-name="java:/iam/im/jdbc/jdbc/WPDS"
<pool>
<min-pool-size>5</min-pool-size>
<max-pool-size>20</max-pool-size>
</pool>
jBoss messaging store:
<bean-instance-pools>
<strict-max-pool instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES" max-pool-size="20" name="slsb-strict-max-pool"/>
<strict-max-pool instance-acquisition-timeout="5" instance-acquisition-timeout-unit="MINUTES" max-pool-size="20" name="mdb-strict-max-pool"/>
</bean-instance-pools>
Identity Manager connecting to Provisioning Server:
Session Pool Maximum Sessions
Min 8
Max 16
Once the connection is made in the provisioning server, what if it is busy doing other things? Threads are used for tasks inside of provisioning server and connecting back to IM through notification.
Provisioning server:
IM_PS.conf
threads 200
C++ connector
IM_CCS.conf
threads 200
JCS:
Uses all defaults from OOTB built in JVM.
Task Persistence Cleanup:
After Connection pools are tuned properly for your business needs, you have to look at data and access to data. Do you have task persistence clean up scheduled? How often does this run?
Task persistence was never meant to be used for Reporting or historical data usage. It is used to report on tasks that have been submitted are in progress and have completed with success or completed with error.
Every time that you submit a task to IM an OID is generated for that task, but MUST be unique, so before that task is submitted to task persistence the OID is searched amongst the task persistence table to see if it exists. So the less data in the tables that faster the searches are.
There are plenty of Tech articles available that discuss task persistence clean up.
Missing Database Indexes:
Even if you are cleaning task persistence regularly, indexing those tables will still help. CA does not create indexes for any of the stores out of the box but if you have many IdentityManger environments or even just one big IdentityManager environment screen indexing can help loading the IME at startup step 5 and can increase speed while reading from and writing to task persistence.
Here is a great post or oracle missing indexes:
https://community.oracle.com/thread/1085346?tstart=0
Here is to for MSSQL:
https://technet.microsoft.com/en-us/library/ms345417%28v=sql.105%29.aspx
Feedback
