Sun Java logo     Previous      Contents      Index      Next     

Sun logo
Sun[TM] Identity Manager 8.0 Tuning, Troubleshooting, and Error Messages 

Chapter 1
Performance Tuning

You can significantly improve Identity Manager performance across nearly all activities with the proper tuning. In addition to changing settings within the software, you can make performance improvements by tuning the application server, Java Virtual Machine (JVM), hardware, operating system, and network topology.

Additionally, you can use several tools to diagnose and monitor performance. Several of these tools exist within Identity Manager, such as trace and method timers. You can also use other Sun Microsystems and third-party tools to debug performance issues with Identity Manager.

This chapter describes tools, methodologies, and references you can use to improve performance and debug performance-related issues.


The tuning process spans many entities and is specific to your deployment environment. This chapter describes different tuning methods for optimizing Identity Manager performance, but these methods are only intended as guidelines. You might have to adapt these methods for your deployment environment.

This chapter covers the following topics:

Before You Begin

Review the information in these sections before starting to tune Identity Manager:

Intended Audience

This chapter is intended for application server and database administrators, front line support engineers, and partners who are interested in optimizing Identity Manager performance.

Before tuning Identity Manager, you must

Important Notes

You should be aware of the following information before trying to tune Identity Manager performance:

Related Documentation and Web Sites

In addition to the information provided in this chapter, consult the publications and web sites listed in this section for information related to tuning Identity Manager.

Recommended Reading

See the following publications for information related to performance tuning.

Table 1-1  Related Documentation

Publication Title


IBM Developer Kit and Runtime Environment, Java Technology Edition, Version 5.0 Diagnostics Guide

Explains how to use AIX JVM to diagnose performance problems. Go to the following web site:

Java Tuning White Paper

Contains information, techniques, and pointers related to Java performance tuning. Go to the following web site:

Oracle MetaLink: Note:114671.1: Gathering Statistics for the Cost Based Optimizer

Explains how to use system statistics and Oracle’s Cost-Based Optimizer. This publication is available to Oracle Metalink subscribers from the following web site:

Note: Registration is required.

Solaris Dynamic Tracing Guide

Sun Java™ System Application Server Performance Tuning Guide

Describes how to obtain optimal performance from your Sun Java System Application Server. Go to the Sun Microsystems Documentation web site:

Tuning Garbage Collection with the 5.0 JavaTM Virtual Machine

Describes how to tune your garbage collector application by using JVM. Go to the following web site:

Turbo-charging Java HotSpot Virtual Machine, v1.4.x to Improve the Performance and Scalability of Application Servers

Explains how to download and use the PrintGCStats script and how to collect statistics to derive optimal JVM tunings. Go to the following web site:

Understanding System Statistics

Describes how Oracle’s Cost-Based Optimizer (CBO) uses system statistics. Go to the following web site:

Using JConsole to Monitor Applications

Describes how to use JConsole to monitor applications that run on the Java platform. Go to the following web site:

Useful Web Sites

The following table describes some web sites you might find useful when trying to tune Identity Manager performance.

Table 1-2  Useful Web Sites

Web Site URL


Sun web site containing diagnostic tools, forums, features and articles, security information, and patch contents.

Note: The information on this site is partitioned into three areas,

  • Internal: Sun employees only
  • Contract: Available only to customers with contract access
  • Public: Available to everyone

Sun Developer Network (SDN) web site where you can browse forums and post questions.

JRat web site that describes how to use the Java Runtime Analysis Toolkit, an open source performance profiler for the Java platform.

Oracle’s internal forum site that contains information about tuning Oracle databases.

Note: You must be a Oracle Metalink subscriber to access the information provided on this site.

NetBeans web site containing information about tuning JVM switches for performance.

Identity Manager link on Sun’s Share Space.

Note: You must sign up for a Share Space ID to access information provided on this site.

Identity Manager FAQ on Sun’s Share Space.

Note: You must sign up for a Share Space ID to access this FAQ.

SLAMD Distributed Load Generation Engine web site.

OpenSolaris Community: DTrace web page.

Web sites containing information related to tuning Solaris.

Tuning Roadmap

How well your Identity Manager solution performs can depend on the following deployment-specific settings:

When you are trying to debug performance problems, start by analyzing and describing the problem. Ask yourself the following questions:

Tuning Your Deployment Environment

This section provides information about tuning your deployment environment, including

Tuning Your Java EE Environment

This section describes some tuning suggestions you can use to optimize your Java EE environment.

These tuning suggestions were derived from a series of experiments in which a considerable increase in throughputs was observed for the use cases tested. The increases were attributed to JVM sizing and to switches that affected Garbage Collector behavior.

Suggestions for tuning your Java EE environment are organized into the following sections:

Tuning Java

For information, best practices, and examples related to Java performance tuning, see the Java Tuning White Paper provided at the following location:

Tuning the JVM

The following tuning scripts were used to derive the tuning suggestions noted in this section. These scripts were added to the domain.xml file (located in the domain configuration directory, which is typically domain-dir/config) on a Sun Java™ System Application Server.

To improve JVM performance

Tuning Your Application Server

The following guidelines are provided to help you tune your application server:

Tuning a Sun Java System Application Server

The “Tuning the Application Server” chapter, in the latest Sun Java™ System Application Server Performance Tuning Guide, contains information about tuning a Sun Java™ System Application Server. This publication is available from

Tuning a WebSphere Application Server

If you are tuning Identity Manager on an IBM WebSphere application server, consider limiting how much memory is allocated for the heap because heap memory can affect the memory used by threads.

If many threads are created simultaneously and the heap size increases, the application’s space limit can be quickly impacted and the following error results:


Tuning Your Repository Database

Identity Manager relies on the repository database to store and manage its identity and configuration data. For this reason, database performance can greatly influence Identity Manager’s performance.


Detailed information about performance tuning and managing databases is beyond the scope of this publication, because this information is dataset-specific and vendor-specific. In addition, customer database administrators (DBAs) should already be experts on their own databases.

This section characterizes the Identity Manager application and provides general information about the nature of Identity Manager data and its typical usage patterns to help you plan, tune, and manage your databases. This information is organized into the following sections:

Repository Table Types

The Identity Manager repository contains three types of tables, and each table has slightly different usage characteristics. Information about these tables is organized into the following sections:

Attribute Tables

Attribute tables enable you to query for predefined single-valued or multivalued object attributes.

For most object types, stored attributes are hard-coded.


The User and Role object types are exceptions to this rule. The inline attributes that are stored in the object table for User and Role are configurable, so you can configure additional custom attributes as queryable.

When you search for objects based on attribute conditions, Identity Manager accesses attribute tables in joins with the corresponding object tables. Some form of join (such as a JOIN, an EXISTS predicate, or a SUB-SELECT) occurs for each attribute condition.

The number of rows in the attribute table are proportional to the number of rows in the corresponding object table. The values distribution might exhibit skew, where multivalued attributes have a row per value and some objects might have more attributes or more attribute values than others. Typically, there is a many-to-one relation between rows in the attribute table and rows in the object table.

Attribute tables have ATTR in the table name.

Change Tables

Identity Manager uses a change table to track changes made to a corresponding object table. These table sizes are proportional to the rate of object change, but the tables are not expected to grow without bound. Identity Manager automatically truncates change tables.

Change tables can be highly volatile because the lifetime of a row is relatively short and new rows can be created frequently.

Access to a change table is typically performed by a range scan on the time-stamp field.

Change tables have CHANGE in the table name.

Object Tables

The Identity Manager repository uses object tables to hold serialized data objects, such as Large Objects (LOBs). Object tables can also hold commonly queried, single-valued object attributes.

For most object types, stored attributes are hard-coded.


The User and Role object types are exceptions to this rule. The inline attributes that are stored in the object table are configurable, and you can configure additional custom attributes as queryable for User and Role.

The number of rows in an object table equals the number of objects being stored. The number of objects stored in each object table depends on which object types are being stored in the table. Some object types are numerous, while other types are few.

Generally, Identity Manager accesses an object table by object ID or name, though Identity Manager can also access the table by using one of the attributes stored in the table. Object IDs and names are unique across a single object type, but attribute values are not unique or evenly distributed. Some attributes have many values, while other attributes have relatively few values. In addition, several object types can expose the same attribute. An attribute may have many values for one object type and few values for another object type. The uneven distribution of values might cause an uneven distribution of index pages, which is a condition known as skew.

Object tables are tables that do not have ATTR or CHANGE suffixes in the table name.

XML Columns

Every object table contains an XML column, which is used to store each serialized object — with the exception of the LOG table-set. Certain LOG table-set optional attributes are stored in the XML column if these attributes are present. For example, if digital signing is enabled.

Data Classes

You can roughly divide Identity Manager data into a number of classes that exhibit similar properties with respect to access patterns, cardinality, lifetime, volatility, and so forth. Each of the following classes corresponds to a set of tables in the repository.

User Data

User data consists of user objects.

You can expect this data to grow quite large because there is an object for each managed identity. After an initial population phase, you can expect a proportionally small number of creates because the majority of operations will be updates to existing objects.

User objects are generally long-lived and they are removed at a relatively low rate.

User data is stored in USEROBJ, USERATTR, and USERCHANGE tables.

Role Data

Role data consists of Role objects, including Roles subtypes such as Business Roles, IT Roles, Applications, and Assets.

Role data is similar to organization data, and these objects are relatively static after a customer deploys Identity Manager.


An exception to the preceding statement is a deployment that is integrated with an external source containing an authoritative set of roles. One integration style might be to feed role changes into Identity Manager, which causes Identity Manager Role data to be more volatile.

Generally, the number of role objects is small when compared to the number of identity objects such as users (assuming that multiple users share each role), but this depends on how each enterprise defines its roles.

Role data is stored in the ROLEOBJ, ROLEATTR, and ROLECHANGE tables.

Account Data

Account data solely consists of account objects in the Account Index.

As with user data, you expect account data to become rather large, with an object for each known resource account. Account objects are generally long-lived, removed at a relatively low rate, and after initial population, are created infrequently. Unless you frequently add or remove native accounts, or enable native change detection, account objects modifications occur infrequently.

Identity Manager stores account data in ACCOUNT, ACCTATTR, and ACCTCHANGE tables.

Compliance Violation Data

Compliance Violation data contains violation records that indicate when the evaluation of an Audit Policy failed. These violation records exist until the same Audit Policy is evaluated against the same User and policy passes. Violation records are created, modified, or deleted as part of an Audit Policy Scan or as part of an Access Review.

The number of violation records is proportional to the number of Audit Policies that are used in scans and the number of Users. An installation with 5000 users and 10 Audit Policies might have 500 violation records (5000 x 10 x 0.01), where the 0.01 multiplier depends on how strict the policies are and how user accounts are changed.

Identity Manager stores Compliance Violation records in OBJECT, ATTRIBUTE, and OBJCHANGE tables.

Entitlement Data

Entitlement data predominately consists of user entitlement objects, which are only created if you are doing compliance access reviews.

Entitlement records are created in large batches, modified slowly (days) after initial creation, and are then untouched. These records are deleted after an Access Review is deleted.

Identity Manager stores entitlement data in ENTITLE, ENTATTR, and ENTCHANGE tables.

Organization Data

Organization data consists of object group or organization objects.

Object group data is similar to configuration data, and this data is relatively static after being deployed. Generally, the number of objects is small (one for each defined organization) when compared to task objects or to identity objects such as users or accounts, but the number can become large compared to other configuration objects.

Organization data is stored in ORG, ORGATTR, and ORGCHANGE tables.

Task Data

Task data consists of objects that are related to tasks and workflows, including state and result data.

The data contained in these tables is short-lived compared to other classes because objects are created, modified, and deleted at a high rate. The volume of data in this table is proportional to the amount of activity on the system.

Task data is stored in TASK, TASKATTR, and TASKCHANGE tables.

Configuration Data

Configuration data consists of objects related to Identity Manager system configuration, such as forms, roles, and rules.

Generally, Configuration data is:

Identity Manager stores configuration data in ATTRIBUTE, OBJCHANGE, and OBJECT tables.

Export Queue Data

If you enable Data Exporting, some records are queued inside Identity Manager until the export task writes those records to the Data Warehouse. The number of records that are queued is a function of Data Exporting configuration and the export interval for all queued types. The following data types are queued by default, and all other data types are not:

The number of records in these tables will grow until the export task drains the queue. The current table size is visible through a JMX Bean.

Records added to this table are never modified. These records are written during other Identity Manager activities, such as Reconciliation, Provisioning, and Workflow Execution. When the Data Exporter export task runs, the task drains the table.

Identity Manager stores Export Queue Data records in QUEUE, QATTR, and QCHANGE tables.

Log Data

Log data consists of audit and error log objects. Log data is write-once only, so you can create new audit and error log objects, but you cannot modify these objects.

Log data is long-lived and can potentially become very large because you can only purge log data by explicit request. Access to log data frequently relies on attributes that are stored in the object table instead of in the attribute table. Both the distribution of attribute values and queries against the log specifically depend on how you are using Identity Manager.

For example, the distribution of attribute values in the log tables depends on

The pattern of queries against the log table also depends on which Identity Manager reports, which custom reports, or which external data mining queries a customer runs against the log table.

Identity Manager stores audit log records in LOG and LOGATTR tables and error log records in SYSLOG and SLOGATTR tables. This data does not have corresponding change tables.

Object IDs

Identity Manager generates globally unique identifiers (GUIDs) for objects by using the VMID class provided in the JDK.

These GUID values exhibit a property that gets sorted by their string representations, based on order in which the objects are created. For example, when you create new objects with Identity Manager, the newer objects have object IDs that are greater than the older objects. Consequently, when Identity Manager inserts new objects into the database, the index based on object ID can encounter contention for the same block or blocks.

Prepared Statements

Generally, Identity Manager uses prepared statements for activities (such as inserting and updating database rows), but does not use prepared statements for queries.

If you are using Oracle, this behavior can create issues with the library cache. In particular, the large number of statements versions can cause contention on the library cache latch.

To address this contention, change Oracle’s CURSOR_SHARING parameter value from EXACT to SIMILAR. Changing this value causes Oracle to replace literals in SQL statements with bind variables, thereby reducing the number of versions.

Character Sets and Encodings

Identity Manager does not restrict which encoding the database uses because Identity Manager is a Java application that generally reads and writes character data rather than bytes.

Identity Manager only requires that the data is sent and returned correctly. For example, the data does not become corrupted when written or re-read.Use an encoding that supports multibyte characters and is appropriate for the customer's data. Generally, UTF-8 encoding is sufficient, but enterprises with a large number of true multibyte characters, such as Asian or Arabic, might prefer UTF-16.

Most database administrators prefer to use an encoding that supports multibyte characters because

General Tuning Guidelines

This section describes some general guidelines for tuning a repository database:

Vendor-Specific Database Tuning Guidelines

This section describes some vendor-specific guidelines for tuning Oracle and SQL Server repository databases.


Currently, MySQL databases are only supported in development and for demonstrations.

Oracle Databases

This section describes guidelines for tuning Oracle repository databases:

SQL Server Databases

Some customers who used a SQL Server 2000 database as a repository reported that as concurrency increased, SQL Server 2000 reported deadlocking problems that were related to SQL Server's internal use of pessimistic locking (primarily lock escalation).

These deadlock errors display in the following format:


==> Transaction (Process ID 51) was deadlocked on lock | communication buffer resources with another process and has been chosen as the deadlock victim. Rerun the transaction.

To prevent or address deadlocking problems,

  1. Use the SQL Server 2005 database.
  2. Configure the READ_COMMITTED_SNAPSHOT parameter. Format the command as as follows:

    Enabling the READ_COMMITTED_SNAPSHOT parameter

    • Removes contention during the execution of SELECT statements that can cause blocks, which greatly reduces the potential for deadlocks internal to SQL Server.
    • Prevents uncommitted data from being read and guarantees that SELECT statements receive a consistent view of committed data.

    • Note

      Go to following URL for more information about the READ_COMMITTED_SNAPSHOT parameter:

Tuning Identity Manager Performance

Suggestions for optimizing Identity Manager’s performance are organized into the following areas:

General Performance Tunings

In general, you can optimize Identity Manager performance if you

Tuning Active Sync Adapter Performance

Because synchronization is a background task, how you configure an Active Sync adapter can affect server performance.

Use the Resources list to manage Active Sync adapters. Choose an Active Sync adapter and access start, stop, and status refresh control actions from the Synchronization section of the Resource Actions list.

To improve Active Sync adapter performance,

Tuning Bulk Loading

To improve performance during bulk load operations,

Tuning Configurable XML Objects

Configurable XML objects offer a broad spectrum of user interface specifications that enable you to define how data is presented to users for different tasks and automate complex business processes. However, this same flexibility can affect efficiency, performance, and reliability.

This section describes some guidelines for tuning Identity Manager’s configurable XML objects, which consist of forms, rules, and workflows. The information is organized into the following sections:

Tuning Forms

You can use Identity Manager forms to define interfaces to interact with views or variable contexts in an executing task. Forms also provide an execution context for business and transformation logic on a set of data elements. Although you can create very powerful, dynamic forms that perform a variety of tasks, reducing the complexity of the form increases efficiency.

The following sections describe some methods for improving the performance of your customized forms

Optimizing New Forms

When designing new Identity Manager forms, system integrators can optimize a form’s performance by

Optimizing Admin Forms

To improve the performance of Admin forms:

Optimizing End User Forms

To improve the performance of End User forms:

Optimizing Expressions in Form Fields

Some activities performed in forms call resources that are external to Identity Manager. Accessing these resources can affect Identity Manager performance, especially if the results contain long lists of values, such as compiling a list of groups or email distribution lists.

To improve performance during these calls, follow the guidelines in “Using a Java Class to Obtain Field Data” in Identity Manager Workflows, Forms, and Views.

Also, avoid using JavaScript in performance-critical expressions such as <Disable> expressions. Short XPRESS expressions are easier to debug if you use the built-in tracing facilities. Use JavaScript for complex logic in workflow actions.

If a form is slow to display, you can use the debug/Show_Timings.jsp page to determine the problem. Look for calls to Formconvert.convertField(). This method shows how long each field took to compute its value.

Tuning Rules

You use Identity Manager rules to encapsulate constants and XPRESS logic that can be reused in forms, workflows, and other configurable components in the product.

When writing rules, use the following guidelines (as applicable) to obtain optimal performance:

Tuning Workflows

You customize Identity Manager workflows to facilitate and automate complex business processes with various human and electronic touchpoints.

You can use the following methods to improve custom workflow performance:

Tuning WorkItems (ManualActions)

The number and size of WorkItems (indicated by ManualActions in a workflow) can affect memory and system performance significantly.

By default, Identity Manager copies an entire workflow context into a WorkItem, then writes the workflow context back out after submission.

To improve performance for ManualActions and WorkItems:

Tuning Database Statistics

As a database administrator, you should frequently run statistics to monitor your repository database.

Performance problems are often caused by bad or missing database table statistics. Fixing this problem improves performance for both the database and Identity Manager performance.

See the following Oracle articles for more information. Website locations are provided in Table 1-1:

Also consider using SQL Profiles, which is another method for choosing the best query plans. You can use the SQL Advisor within Enterprise Manager to create these profiles when you identify poorly performing SQL.

Tuning Data Exporter

Data Exporter enables you to export new, changed, or deleted Identity Manager data to an external repository that is suitable for reporting or analytic work. The actual exporting of data is done in batches, where each type of data to be exported is able to specify its own export cycle. The data to be exported comes from the Identity Manager repository and, depending on the length of the export cycle and the amount of changed data, the volume of exported data can be large.

Some Identity Manager data types are queued into a special table for later export. Specifically, WorkflowActivity and ResourceAccount data is queued because this data is not persisted otherwise. Any persisted data type can also be queued if the warehouse needs to see all changes to the type, or if the type has a lifecycle that does not correspond to the export cycle, such as TaskInstance and WorkItem data.

To maximize performance, only queue and export the types of data that you require in the warehouse. Data exporting is disabled by default, but if you enable data exporting, it exports all data types. Turn off any data types that you do not need.

When the export task exports data, the task attempts to complete the export as quickly as possible, using multiple threads to achieve as much throughput as possible. Depending on the I/O speed of the Identity Manager repository and the warehouse, the export task can fully utilize the processors on the Identity Manager server, which causes any interactive performance to suffer. Ideally, the export should occur on a machine dedicated to that task or at least occur during periods when there is no interactive activity on the machine.

The export task supports the following tuning parameters:

The drain thread count is the most important throughput. If there is a large number of records in the queue table, increasing the number of threads (up to 24) tends to increase throughput. However, if the queue is dominated by one type of record, fewer drain threads might actually be faster. The export task attempts to divide the queue table contents into as many sets as there are threads allocated, and give each thread a set to drain. Note that these threads are in addition to the drain threads that are draining the other repository tables.

Tuning the General XML

You can usually optimize the general XML by using static XMLObject declarations wherever possible. For example, use

Also, depending on the context, you might have to wrap objects instead of using the <o></o> element.

Tuning Identity Manager Service Provider

You can use Identity Manager dashboard graphs to quickly assess the current system, spot abnormalities, and understand historical trends (such as concurrent users or resource operations over a time period) for Identity Manager Service Provider.


Service Provider does not have an Administrative interface. You use Identity Manager’s Administrative interface to perform almost all administrative tasks (such as viewing dashboard graphs).

For more information about tuning Sun Java™ System Identity Manager Service Provider (Service Provider) see the latest version of Identity Manager Service Provider Deployment, which is available from the following location:

Tuning the Identity Manager Web Interface

When you are working with the Identity Manager Web Interface, you can optimize performance by using the OpenSPML toolkit that is co-packaged with Identity Manager.


Using the openspml.jar file from the web site might cause memory leaks.

Tuning Initial Loads

To improve performance during a large, initial user load:

Tuning Memory Requirements

You must determine your memory needs and set values in your application server's JVM by adding maximum and minimum heap size to the Java command line. For example

java -Xmx512M -Xms512M

To improve performance

Tuning Operating System Kernels

For information about tuning Solaris and Linux operating system kernels, see the “Tuning the Operating System” chapter in the Sun Java System Application Server Enterprise Edition 8.2 Performance Tuning Guide.

For information about tuning Oracle operating system kernels, see the product documentation provided with your Oracle system.

Tuning Provisioner

Network latency tends to be a popular cause for performance issues when dealing with view provisioning. Tracing individual resource adapters can help you determine what is causing performance problems.

To improve provisioner performance

Tuning Reconciliation

The Reconciler is the Identity Manager component that performs reconciliation. This section suggests methods for improving Reconciler performance, including

General Tuning Suggestions

In general, you can improve Reconciler performance if you

Tuning the Reconciler Server Settings

Although the default settings are usually adequate, you can sometimes improve Reconciler performance if you adjust the following settings on the Edit Server Settings page:

During idle times, the threads stop if they have no work to do, but only down to the minimum number of threads specified. As the load increases, the Reconciler adds more threads until the maximum number of threads is reached. The Reconciler never has less than the minimum number of threads or more than the maximum.

Generally, more threads allow more concurrency; but at some point, too many threads can put too much load on the machine or just do not provide additional benefit.


Recommending generic, optimal settings is not possible because deployments are so different. Reconciler settings must be adjusted differently for each deployment environment.

To change the Reconciler server settings:

  1. Log into the Administrator interface.
  2. Select the Configure > Servers > Reconciler tabs.
  3. When the Edit Server Settings page displays, adjust the settings as necessary.

  4. Note

    See “Configuring Identity Manager Server Settings” in Identity Manager Administration for more information.

Tuning Reconciliation for Multiple Resources

If you are configuring reconciliation for multiple resources in Identity Manager, you have several options:

An ideal solution does not exist for this configuration because deployments are so different. You might have to mix and match these options to find an acceptable solution for your deployment.

Preparing a usage survey, based on the business reasons behind this functionality might help you decide how to proceed. Ask yourself these questions:

Also, remember that the reconciliation server does not have to be one of the pools that handles web traffic. You can add a server that you never interact with directly because this server exists solely for transaction processing. Having a server dedicated to transaction processing might make the first option more attractive for very large systems.

Tuning Resource Queries


Network latency tends to be a popular cause of performance issues during view provisioning. Tracing individual resource adapters can help you determine what is causing performance problems.

You can improve resource query performance if you use FormUtil.getResourceObjects to implement the query.

Use one of the following methods to cache query results:

Tuning the Scheduler

The Scheduler component controls task scheduling in Identity Manager. This section suggests methods for improving Scheduler performance, including:

General Tuning Suggestions

The following TaskDefinition options determine how the Scheduler handles tasks after they are completed:

These default settings are designed to optimize memory by shortening the lifetime of finished Scheduler tasks. Unless there is a compelling reason to change these settings, leave the default values set.

If you want to immediately delete tasks that completed successfully, but you also want to keep tasks containing errors long enough to debug, you can

Tuning the Scheduler Server Settings

You can sometimes improve Scheduler performance by adjusting the following settings on the Edit Server Settings page:

To change the Scheduler server settings:

  1. Log into the Administrator interface.
  2. Select the Configure > Servers > Scheduler tabs.
  3. When the Edit Server Settings page displays, adjust the settings as necessary.

  4. Note

    See “Configuring Identity Manager Server Settings” in Identity Manager Administration for more information.

Tuning Sessions

Identity Manager maintains a least recently used (LRU) cache of authenticated sessions for use by authenticated users. By using existing authenticated sessions, you can speed up repository access for objects and actions that require a session.

To optimize the authentication pool size, change the session.userPoolSize value in the file to the maximum number of expected, concurrent user sessions on the server.

Tuning the Sun Identity Manager Gateway

The Sun Identity Manager Gateway generates a thread for each connection, and uses a different pool for each unique combination of resource type, Gateway host, and Gateway port. The Gateway checks for idle connections every five minutes and when a connection has been idle for 60 seconds, the Gateway closes and removes that connection from the pool.

When the Gateway receives a request,

You must configure the maximum number of connections on the resource, and you must configure these connections the same way for all resources of the same type, that are using the same Gateway. For that resource type, the first connection made to the Gateway on a given host and port uses that resource's maximum connections value.


When you change the maximum number of connections on a resource, you must start and stop the server for the change to take effect.

The following example shows how connections, requests, and Gateway threads are related:

If you set the maximum number of connections to ten on an Active Directory resource, and you are using two Identity Manager servers, then you can have up to 20 simultaneous connections (ten from each Identity Manager server) to the Gateway for that Active Directory resource. The Gateway can have ten simultaneous requests outstanding from each server, and the Gateway processes each request on a different thread. When the number of simultaneous requests exceeds the maximum number of Gateway connections, additional requests are queued until the Gateway completes a request and returns the connection to the pool.


Although the Gateway code is multithreaded, this characteristic does not address the APIs or services being used by the Gateway. For Active Directory, the Gateway uses the ADSI interface provided by Microsoft. No investigation has been done to determine whether this interface handles Gateway requests in parallel.

Other methods for improving Gateway performance, include:

Tuning the Task Bar

The Administrative interface task bar displays links to previously performed provisioning tasks, which causes the interface to render more slowly when there are a large number of tasks.

To improve interface performance, remove the taskResults.jsp link from all JSPs by deleting the <List>...</List> element from the UserUIConfig object.

The following example shows <List>...</List> entries within <TaskBarPages>:

Code Example 1-2  Modifying the UserUIConfig Object


Debugging Performance Issues

This section describes the different Identity Manager and third-party debugging tools you can use to debug performance issues. The information is organized into the following sections:

Working with Identity Manager Debug Pages


Tracing affects system performance. To help ensure optimal performance, specify the minimum tracing level or turn tracing off after debugging the system.

This section provides instructions for accessing the Identity Manager debug pages describes how to use these pages to identify and debug Identity Manager performance issues. See the following sections for information:

Accessing the Debug Pages


You must have the Debug, Security Administrator, or the Waveset Administrator capabilities to access and execute operations from the Identity Manager Debug pages. Administrators and the Configurator are assigned this capability by default.

If you do not have the Debug capability, an error message results.

To access the Identity Manager debug pages:

  1. Open a browser and log in to the Identity Manager Administrative interface.
  2. Type the following URL into the browser:
  3. http://host:port/idm/debug


    • host is the application server on which you are running Identity Manager.
    • port is the number of the TCP port on which the server is listening.
  4. When the System Settings page displays, type the .jsp file name for the debug page you want to open. For example
  5. http://host:port/idm/debug/pageName.jsp


    Some debugging utilities are not linked from the System Settings page, but you can use them to enhance your ability to gather data for product performance and usability. For a complete list of debug pages, open a command window and list the contents of the idm/debug directory.

Control Timings (callTimer.jsp)

Use the Control Timings page to collect and view call timer statistics for different methods. You can use this information to track bottlenecks to specific methods and invoked APIs. You can also use options on the Call Timings page to import or export call timer metrics.


Call timing statistics are only collected while trace is enabled.

To view call timer statistics

  1. Open the Control Timing page, and click Start Timing & Tracing to enable trace and timing.
  2. To stop the timing, click Stop Timing & Tracing or click Stop Timing.
  3. The page redisplays and populates the Show Timings table with a list of methods for which statistics are available and the methods’ aggregate call timer statistics (not broken down by caller). This table contains the following information:

    • Method name (Click a method name to see which methods it calls.)
    • Total time
    • Average time
    • Minimum time
    • Maximum time
    • Total calls
    • Total errors
  4. To clear the list, click Clear Timing.

  5. Note

    You can also use the callTimer command to collect call timer data from the Console. This command is useful when you are debugging performance issues during an upgrade or in other situations where Identity Manager is not running on the application server.

Edit Trace Configuration (Show_Trace.jsp)

Use the Edit Trace Configuration page to enable and configure tracing for the Java classes provided with your Identity Manager installation.

Specifically, you can use this page to configure the following trace settings:

Host Connection Pool (Show_ConnectionPools.jsp)

If you are not using a data source, you can use the Host Connection Pool page to view connection pool statistics. These statistics include the pool version, how many connections were created, how many are active, how many connections are in the pool, how many requests were serviced from the pool, and how many connections were destroyed.

You can also use the Host Connection Pool page to view a summary of the connection pools used to manage connections to the Gateway. You can use this information to investigate low-memory conditions.

List Cache Cleared (Clear_XMLParser_Cache.jsp)

Use the List Cache Cleared page to clear recently used XML parsers from the cache and to investigate low memory conditions.

Method Timings (Show_Timings.jsp)

Use the Method Timings page to quickly detect and assess hotspots at a method level. The following information is gathered from Identity Manager methods and displayed on the Method Timings page:

The Method Timings page also contains a table with the following links (click these links to view additional information):

Object Size Summary (Show_Sizes.jsp)

Use the Object Size Summary page to detect problematically large objects that can affect your system.

The Object Size Summary page shows information about the size of objects (in characters) stored in the repository. These objects are listed by type, along with the total number of objects of each type, and the objects’ total combined size, average size, maximum size, and minimum size.

Click entries in the Type column to view additional size information about each specific object type. For example, click Configuration to view the ID, name, and size of the largest configuration objects in the repository.

You can also access this size information from the console command line.

  1. Open the console.
  2. At the command prompt, type:
  3. showSizes [<type> [<limit>]]


    For upgrades, existing objects will report a size of 0 until they have been updated or otherwise refreshed.

Provisioning Threads for Administrator Configurator (Show_Provisioning.jsp)

Use the Provisioning Threads for Administrator Configurator to view a summary of the provisioning threads in use by the system (a subset of the information available in Show_Threads.jsp).


Looking at just a single thread dump can be misleading.

System Cache Summary (Show_CacheSummary.jsp)

Use the System Cache Summary page to view information about the following items to help you investigate low-memory conditions:

System Memory Summary (Show_Memory.jsp)

Use the System Memory Summary page to view how much total and free memory you have available in Mbytes. When you are using memory-intensive functionality such as Reconciliation, this information can help you determine whether there is sufficient memory allocated to the JVM.

You can also use this page to launch garbage collection or to clear unused memory in the JVM for investigating heap usage.

System Properties (SysInfo.jsp)

This page also provides information about your environment, including software versions, paths and environmental variables.

System Threads (Show_Threads.jsp)

Use the System Threads page to see which processes are running so you can verify that automated processes (such as reconciliation or Active Sync) are running.

This page includes information about the process type, process name, its priority, if the process is a daemon and if the process is still alive (running).


Looking at just a single thread dump can be misleading.

User Session Pool Cleared (Clear_User_Cache.jsp)

Use the Session Pool Clearer page to clear all of the cached sessions for users who have recently logged in and to investigate low memory conditions.

Waveset Properties (Show_WSProp.jsp)

Use the Waveset Properties page to view and temporarily edit properties in the file. You can test different property settings for a particular server on which the file resides without having to restart the server to pick up the changes. The edited property settings only remain in effect until the next time you restart the server.

XML Resource Adapter Caches Flushed and Cleared (Clear_XMLResourceAdapter_Cache.jsp)

Use the XML Resource Adapter Caches Flushed and Cleared page to clear test XML resource adapters from the cache and to investigate low memory conditions.

Working With Other Debugging Tools

You can use the following Sun Microsystems’ and third-party tools to identify potential performance bottlenecks — especially if your deployment uses custom Java classes:

Identity Manager Profiler

Identity Manager provides a Profiler utility to help you troubleshoot performance problems in your deployment.

Customized forms, Java, rules, workflows, and XPRESS can cause performance and scale problems. The Profiler profiles how much time is spent in these different areas, enabling you to determine whether these forms, Java, rules, workflows, or XPRESS objects are contributing to performance and scale problems and, if so, which parts of these objects are causing the problems.


For more information about JProfiler, see “Working with the Identity Manager Profiler” in the Identity Manager 8.0 Release Notes.


DTrace is a dynamic tracing framework for the Solaris 10 operating environment that enables you to monitor JVM activity.

DTrace provides more than 30,000 probes and uses integrated user- and kernel-level tracing to give you a view into your production system. You can also trace arbitrary data and expressions by using the D language (similar to C or awk).

The DTrace facility

The following example shows how to write a DTrace script:

Code Example 1-3  Example DTrace Script

#!/usr/sbin/dtrace -Zs

#pragma D option quiet



printf("%s\n", probename);


In this example, you would replace $1 with the first argument to the script, which is the PID of the Java process you want to monitor. For example

# ./all-jvm-probes.d 1234

Use the following commands to enable different DTrace probes:

Table 1-3  DTrace Commands  




Enables JVM support in Java 6 (patches for 1.4 and Java 5)


Provides the following information:

  • JVM startup (begin and end) and shutdown
  • Thread starting and stopping
  • Class loading and unloading
  • Garbage collection (several options available)
  • JIT compilation begin and end
  • Compiled method loading and unloading
  • Monitor contention, wait and notify
  • Method entry, method return, and object allocation

/usr/sbin/dtrace -n 'hotspot*:::'

Enables all JVM probes for all Java processes on the system

/usr/sbin/dtrace -n 'hotspot1234:::'

Enables all JVM probes for only the Java process with PID 1234

/usr/sbin/dtrace -n 'hotspot1234:::gc-begin'

Enables only the probe that starts when garbage collection for process 1234 begins


Because DTrace causes additional work in the system, enabling this facility affects system performance. The effect is often negligible, but can become substantial if you enable many probes with costly enablings.

Instructions for minimizing the performance effect of DTrace are provided in the “Performance Considerations” chapter of the Solaris Dynamic Tracing Guide. You can view this publication from the following location:

For more information about DTrace, see /usr/demo/dtrace and man dtrace.


The Java Monitoring and Management Console (JConsole) is a Java Management Extension (JMX) technology-compliant graphical management tool that is co-packaged with JDK 5 (and later). JConsole connects to a running JVM and gathers information from the JVM MBeans in the connected JMX agent.

Specifically, you can use JConsole to

Identity Manager supplies some JMX Mbeans that provide information about:


You can use the Java Runtime Analysis Toolkit (JRat), an open-source performance profiler for the Java platform, to identify potential performance bottlenecks, especially if your deployment uses custom Java classes. JRat monitors your application’s execution and persists the application’s performance measurements.

For example, if you have a custom workflow for provisioning, you can use JRat to see which classes are being invoked and how much time is required to run your workflow compared to the default Identity Manager provisioning workflow.


For more information about JRat, see the following web site:

Previous      Contents      Index      Next     

Part No: 820-2962-10.   Copyright 2008 Sun Microsystems, Inc. All rights reserved.