StarTeam Memory Management
In System-level Performance and Resource Metrics, we briefly mentioned that the memory used by the StarTeam server process grows for a while before plateauing off. In this Article, we look at some of the steps we can take to compensate, mitigate and curb this memory growth, particularly if the memory usage happens to be getting close to the 2 GB limit.
The techniques presented here are relevant to StarTeam server versions 7.0-9.0. All the options presented here in the format refer to options in the StarTeam server configuration file ("starteam-server-configs.xml").
1. 4GT Ram Tuning
This increases the memory available to the StarTeam process from the OS (up from 2 GB to 3 GB). StarTeam is compiled to detect when it is running on a 4GT Ram Tuned system, and it will automatically tell Windows that it wants to use this feature.
2. Component Caching
TopicsCaching" value="0">TasksCaching" value="0">
Examine the XYZCaching options (e.g., FilesCaching, ChangeRequestsCaching, etc.) You could be running some options with higher values than you need. The three possible values for these options are:
"2" - server pre-loads the tip revisions of all XYZ (File, CR, Task, or Topic) from all Views
"1" - server caches the tip revisions of XYZ only on demand (when they are first requested)
"0" - server does not cache tip revisions of XYZ
Note the memory saving you can get in using a value of "1" as opposed to a "2", particularly in the case of CRs. Value "2" means that the server caches the tip properties of all CRs at start-up. As CRs are modified/added, the older CR revisions are not cached, but the newer ones are. The result is great performance for things like full-scope on CRs, but the cost is increased server memory usage. Because CRs have more (and longer) properties than say files, the value="2" setting almost always has a major impact on server memory. (Possibly up to 50%.)
On the other hand, running with caching set to "1" causes the server to cache tip CR revisions only after they are actually first requested. This makes the server start-up a little faster and reduces memory by not caching revisions that no one asks for. The cost is that the first user to ask for a tip CR revision causes it to be retrieved from the database, which takes a little longer than pulling it from memory cache. If the first user after a server restart performed full-scope on a view with 10,000 CRs, they"d probably notice a difference with value="1" instead of "2". Second and subsequent users shouldn"t see any performance difference at all.3. Min/MaxCommandThreads & Pooled Database Connections
IDSCachePurge = 0 or not set: purge feature turned off.
IDSCachePurge = 1: purge feature turned on.
(Note: The server must be restarted for the setting to take effect.)
The "IDS cache" caches data for tip revisions of all items and thus, improves the server performance. Currently, the cache has no upper limit, and for certain datasets, it reaches the point where the cache uses all memory available to the process. The "IDS Cache Purging" technique controls the amount of memory used by the IDS cache, while still providing optimal performance for most used items.5. Server Restarts Restart the server more often. Especially if you have old views that become obsolete and no longer used (even though not deleted). Since some caching is performed on every view once it is opened (even after all users have closed it), restarting the server allows it to toss the cached data from these older views.