Troubleshooting
Problem
Users running IBM Engineering Requirements Management DOORS Next versions 6.X might experience slow performance executing common use cases.
Symptom
Users might experience poor performance or timeout warnings when performing common use cases within the application.
Cause
Configuration caches might need to be adjusted from their default levels to accommodate larger data sets as the number of active configurations (non-archived streams and baselines) increases. Note: It is recommended to increase the JVM heap size to 16 GB or higher when the caches are set to a value over 1,000 as each cache entry uses up to 2 MB of heap space.
If after investigation your server's configuration cache sizing is adequate for your repository and so is not a likely cause of performance problems, refer to Performance issues and CRRRW7556E after upgrading IBM Rational DOORS Next Generation (DNG) repository for further common performance tuning recommendations.
Environment
IBM Engineering Requirements Management DOORS Next versions 6.X.
Diagnosing The Problem
To diagnose the problem, the server must be started with the following JVM argument in place. To set the JVM parameter on WebSphere Application Server, refer to Setting generic JVM arguments in WebSphere Application Server. This setting can be left in place without any performance degradation as this is enabled by default starting in 6.0.3.
-Dcom.ibm.team.repository.service.internal.vvc.enableCounters=true
For Tomcat or WebSphere Liberty, the argument can be applied by adding the following line in the JVM arguments section in the startup script.
set JAVA_OPTS=%JAVA_OPTS% -Dcom.ibm.team.repository.service.internal.vvc.enableCounters=trueOnce the setting is in place and the server has been started, execute several of the poor performing use cases on the system. Once complete, navigate to the following page:
https://<server>:<port>/rm/service/com.ibm.team.repository.service.internal.counters.ICounterContentService/
Search for the section called "Local Configuration Management Cache Statistics".
Cache limits vary based on the release being used, so caution must be taken when tuning the cache in order to ensure that proper tuning is being applied. Red flags to look for on any row in the table include "
cnt" values that are higher than the current cache limits, especially when "avg"/"max" values closely match the current cache limits. Example: In this example (taken from a 6.0.6.1 server), the ConfigurationCache "
cnt" exceeds 8M while the "avg"/"max" is only 2000. This indicates a high level of cache turnover, as the cache is only able to handle 2000 values (default for 6.0.4 and beyond). It is important to note that the total count of active configurations does not align with the 8M "cnt" value observed; the SQL query that is given can be used to determine the total number of active configurations.Local Configuration Management Cache Statistics Table
If a red flag is found, run this SQL query against the database:
Number of Active (non-archived) configurations in the Repository:
For SQL Server & DB2:
DOORS Next 6.x:SELECT COUNT(*) FROM VVCMODEL.CONFIGURATION WHERE ARCHIVED = 0;
For Oracle:
For DOORS Next 6.x, use:
SELECT COUNT(*) FROM VVCMODEL_CONFIGURATION WHERE ARCHIVED = 0;
If the result of the SQL query exceeds the default values that are found in this table (or any existing cache values set in your environment), cache tuning is required.
Resolving The Problem
There are both short-term and medium-longer term aspects to resolving this performance problem.
In the medium-longer term, you might be able to adapt your requirements process to reduce the pressure on the configuration caches (and this also reduces the pressure on JVM heap size) by, for example, adopting a policy of routinely archiving unused configurations (for example, as phases of work finish or as projects are completed) - this helps minimize the number of active configurations and so reduce the need for increased cache size and the related impact on JVM heap size. See more information in the JVM Heap Note.
In the short-term, you can tune the cache parameters to reflect at least the current number of configurations in the repository.
If your repository is expected to increase the number of projects, baselines or configurations, then consider setting the cache parameters to a value larger than the current number of configurations returned by the SQL query.
If the result exceeds the defaults in the table Local Configuration Management Cache Statistics, set the values in the JVM settings that are detailed here to at least the current number of configurations returned by the Number of Active (non-archived) configurations in the Repository query - but see the JVM Heap Note for changes that might be needed to JVM heap size, and how to work with IBM support if numbers greater than 5000 are indicated.
-Dcom.ibm.rdm.configcache.expiration=4320
-Dcom.ibm.rdm.configcache.size={# of configs from query}
-Dcom.ibm.team.repository.service.internal.vvc.noOfConfigsToCache={# of configs from query}
-Dcom.ibm.team.repository.service.internal.vvc.ConfigurationIdCache.noOfConfigsToCache={# of configs from query}
-Dcom.ibm.team.repository.service.internal.vvc.noOfComponentsToCache=2000
-Dcom.ibm.team.repository.service.internal.vvc.noOfContextsToCache=2000JVM Heap Note:
Each cache entry consumes approximately 2 MB of JVM heap. As a result, it is not recommended to set or increase cache tuning to values to greater than 5000 without explicit recommendation from IBM Support. It is also recommended that customers monitor JVM heap usage after setting any non-default cache tuning in their environment, as the current heap values may no longer be sufficient after increasing cache sizes.
Each cache entry consumes approximately 2 MB of JVM heap. As a result, it is not recommended to set or increase cache tuning to values to greater than 5000 without explicit recommendation from IBM Support. It is also recommended that customers monitor JVM heap usage after setting any non-default cache tuning in their environment, as the current heap values may no longer be sufficient after increasing cache sizes.
[{"Business Unit":{"code":"BU059","label":"IBM Software w\/o TPS"},"Product":{"code":"SSUVLZ","label":"IBM Engineering Requirements Management DOORS Next"},"ARM Category":[{"code":"a8m50000000Cj1gAAC","label":"DOORS Next Generation->Administration"}],"ARM Case Number":"TS003616662","Platform":[{"code":"PF025","label":"Platform Independent"}],"Version":"6.0;6.0.1;6.0.2;6.0.3;6.0.4;6.0.5;6.0.6;6.0.6.1","Line of Business":{"code":"LOB59","label":"Sustainability Software"}}]
Was this topic helpful?
Document Information
Modified date:
29 June 2022
UID
swg21995500