How do I improve the performance of ssoadm in AM (All versions)?

Last updated Jan 16, 2023

The purpose of this article is to provide information on improving the performance of ssoadm in AM.

3 readers recommend this article

Improving the performance of ssoadm

There are five things you can try to improve the performance of ssoadm:

Use the do-batch command.
Increase the ssoadm heap size.
Use a client VM.
Add the --nolog option to the ssoadm command (update-entity-keyinfo command).
Add a Java option to change how random bits are generated (Linux® systems only).

Establishing a baseline

You can add time before the ssoadm command to output the execution time of the ssoadm command, which will help you assess the effect of any changes you make. It is recommended you run a simple command, such as the following, prior to making any changes to give you a baseline:

AM 7 and later: $ time ./ssoadm list-servers -u uid=amAdmin,ou=People,dc=am,dc=forgerock,dc=org -f pwd.txt
AM 6.x: $ time ./ssoadm list-servers -u amadmin -f pwd.txt

You can then repeat this command after making changes to assess the impact.

Using the do-batch command

You can use the ssoadm do-batch command to run multiple ssoadm commands; using this command means multiple ssoadm commands are executed together in a single JVM call, rather than as individual JVM calls, which speeds up processing time.

See How do I make batch changes using ssoadm in AM (All versions)? for further information.

Increasing the ssoadm heap size

The default ssoadm heap size settings are:

-Xms256m -Xmx512m

You can increase these values (providing you have enough physical memory) to improve ssoadm performance. Initially, you should try setting both Xms and Xmx to 1024m; Xms and Xmx should be the same for the best performance.

You can increase the ssoadm heap size values as follows:

Edit the ssoadm or ssoadm.bat script and update the following line: $JAVA_HOME/bin/java -Xms1024m -Xmx1024m -cp "$CLASSPATH" \
Save your changes.

Note

You can update the ssoadm.template or ssoadm.bat.template file (located in the /path/to/ssoadm/tools/template/unix/bin or /path/to/ssoadm/tools/template/windows/bin directory respectively) prior to installation instead; this means ssoadm will be installed with these default values. This approach is useful if you have multiple installations or do automated installs.

Using a client VM

The JDK offers both a client VM and a server VM; the client VM is tuned for reduced startup times and memory footprint, but typically the server VM is used by default. See Java Virtual Machine Technology Overview for further information.

You can force ssoadm to use the client VM as follows:

Edit the ssoadm or ssoadm.bat script and update the following line: $JAVA_HOME/bin/java -Xms1024m -Xmx1024m -client -cp "$CLASSPATH" \
Save your changes.

Note

Adding the --nolog option to the ssoadm command

The --nolog option can be added to a command to disable audit logging for that command.

You can add it to the ssoadm update-entity-keyinfo command if the command fails with the following error:

java.lang.IndexOutOfBoundsException: Index: 7, Size: 7

Adding a Java option to change how random bits are generated

In some situations, running ssoadm on Linux systems can result in performance issues; this is particularly true if you are using a virtual machine. When this happens, you will see a stack trace similar to the following when generating the SSOToken ID:

"main" prio=10 tid=0x00007f806400c000 nid=0x7e3f runnable [0x00007f8068918000] java.lang.Thread.State: RUNNABLE at java.io.FileInputStream.readBytes(Native Method) at java.io.FileInputStream.read(FileInputStream.java:272) at sun.security.provider.SeedGenerator$URLSeedGenerator.getSeedBytes(SeedGenerator.java:526) at sun.security.provider.SeedGenerator.generateSeed(SeedGenerator.java:139) at sun.security.provider.SecureRandom$SeederHolder.(SecureRandom.java:186) at sun.security.provider.SecureRandom.engineNextBytes(SecureRandom.java:203) - locked <0x00000000ed1684f0> (a sun.security.provider.SecureRandom) at java.security.SecureRandom.nextBytes(SecureRandom.java:455) - locked <0x00000000ed168790> (a java.security.SecureRandom) at java.security.SecureRandom.next(SecureRandom.java:477) at java.util.Random.nextLong(Random.java:334) at com.sun.identity.authentication.internal.AuthContext.getSSOToken(AuthContext.java:842) at com.sun.identity.setup.Bootstrap.getSSOToken(Bootstrap.java:289) at com.sun.identity.setup.Bootstrap.getConfiguration(Bootstrap.java:203) at com.sun.identity.setup.Bootstrap.load(Bootstrap.java:135) at com.sun.identity.setup.Bootstrap.load(Bootstrap.java:92) - locked <0x00000000eb0536e0> (a java.lang.Class for com.sun.identity.setup.Bootstrap) at com.sun.identity.cli.CommandManager.main(CommandManager.java:113)

To improve the performance in this situation, you can add the following JVM option to the ssoadm script:

-D"java.security.egd=file:/dev/./urandom" \

Related Training

N/A

Related Issue Tracker IDs

N/A