When the Microsoft® Windows® operating system starts, it reserves various areas of memory for tracking its resources. One of these is the relatively unknown desktop heap. On Windows-based systems, the desktop heap stores information about the various processes running on the machine. Memory allocation of the heap is controlled by the number of open applications, windows, services and other resources. When a large number of processes are running, this heap may run out of memory.
How this memory is allocated has implications in your ClearCase environment when considering overall performance and system architecture. This article describes how to modify the amount of memory assigned to the desktop heap according to the number of ClearCase clients, processes, and hosted VOBs and views, and give some tips about when you might consider scaling your system or re-allocating other Windows-based resources.
Modifying heap size
The different values for the desktop heap are stored in the following Windows registry value:
To start the Windows registry editor, click Start > Run, and enter:
regedt32. You can then expand the folders listed above in the left (navigation) pane of the Registry Editor to display the value of these settings in the view pane. The default data for this registry value will look something like the following (all on one line):
%SystemRoot%\system32\csrss.exe ObjectDirectory=\Windows SharedSection=1024,3072,512 Windows=On SubSystemType=Windows ServerDll=basesrv,1 ServerDll=winsrv:UserServerDllInitialization,3 ServerDll=winsrv:ConServerDllInitialization,2 ProfileControl=Off MaxRequestThreads=16
The numeric values following
SharedSection= control how desktop heap is allocated. These "SharedSection" values are specified in kilobytes. There are separate settings for desktops associated with interactive and noninteractive window stations.
The first SharedSection value (1024) is the shared heap size common to all desktops. This includes the global handle table, which holds handles to windows, menus, icons, cursors, and so forth, and shared system settings. It is unlikely that you would ever need to change this value.
The second SharedSection value (3072) is the size of the desktop heap for each desktop that is associated with the "interactive" window station WinSta0. User objects like hooks, menus, strings, and windows consume memory in this desktop heap. It is unlikely that you would ever need to change this second SharedSection value.
The third SharedSection value (512) is the size of the desktop heap for each desktop that is associated with a "noninteractive" window station. If this value is not present, the size of the desktop heap for noninteractive window stations will be same as the size specified for interactive window stations (the second SharedSection value).
This section of the heap is used to keep track of the processes that are running without graphical user interfaces. All ClearCase processes are managed through the settings in this heap. Due to its client/server architecture ClearCase uses a lot of processes. There is one for each VOB or view hosted by the server, at least one for each client accessing resources hosted on the server, and numerous worker processes handling requests that are created and destroyed as required.
From figures provided by practical experience it appears that each process requires a 6.5 Kbyte slot in the desktop heap. The number of ClearCase processes that can run for a given heap size is calculated as follows:
Prior to Windows NT v3.5, Microsoft recommended a heap size of 3000 Kbytes (allowing for 460 processes). For later versions of NT and for Windows 2000 they recommend a size of only 512 Kbytes (allowing for 79 processes). It is clear that the size of the heap is the limiting factor controlling how many ClearCase resources may be installed on a given server. Indeed it can be seen that if the desktop heap size is kept at the Microsoft recommended value using high-specification servers will be wasteful since most of their power will not be used. A large number of low-specification servers would need to be used with an attendant increase in support costs.
Increasing the heap size beyond 512 Kbytes can cause instability or "blue-screening" of the server but the factors involved are sometimes obscure. Possibly, increasing the heap size depletes some other vital resource. However, in some ClearCase environments there are servers running with a heap size of 3072 Kbytes. It would appear from this evidence than it is safe to run a Windows 2000-based server with a heap size of 3072 kilobytes if only ClearCase services are installed. We have seen the "blue screen of death" in servers having a higher heap size with IIS and SQL server. This change maximizes the size of desktop heaps created by non-interactive services to 3072 KB, to support about 500 processes. The trade-off is that the host will support more processes but overall performance will decrease. If performance is degraded too much for your customer's taste, scale back the desktop heap size. Now be aware that you need to know how many users you plan on supporting with this server, because more view or VOB servers may be needed. This is a Windows limitation and not strictly a ClearCase issue. This is one of the reasons IBM Rational recommends distributed view servers (local to the user's host) to share the load rather than one dedicated view server. (UNIX machines typically make better VOB servers.)
Calculating process requirements for views
Each view requires one view server process. Note that these processes are only started when the first client accesses a view but could remain active even after all clients have disconnected from the view. Only the stopping of ClearCase will insure the killing of these processes. Therefore, assuming that all views are going to be accessed, the number of processes that must be available to service views is equal to the number of views.
How many Windows view host servers do you need?
To get the number of view host servers we simply divide the number of views by the processes available on a server.
Calculating process requirements for VOBs
Each VOB server hosts one or more VOBs. A VOB consists of seven files on disk that provide the storage for the documents stored in the VOB. An instance of the VOB server process manages the access to each VOB. Each request to access a VOB is handled by a
vobrpc_server process. The number of these processes existing at any one time is dependant on access frequency; they are deleted when they become inactive. Practical experience allows us to estimate that for a typical ClearCase installation between 1 and 1.5 of these processes exist per VOB at any moment.
Each ClearCase client that is accessing VOBs on the VOB server requires at minimum one
db_server process to mediate access to the VOBs. A single
db_server process can handle access to, at most, four VOBs. If the client needs access to more than four VOBs on a single VOB server machine, then additional
db_server instances are created. Again, experience suggests a factor of between 1 and 1.5 per client be used to calculate the total number of these processes across all VOB servers.
Obviously the numbers of
db_server process that exist on any VOB server machine is very dependent upon the distribution of the VOBs referenced by Unified Change Management (UCM) projects across all VOB servers. If all VOBs involved in a project are on one server, then fewer processes are required than if each is hosted on a different server.
Given the foregoing we can define the following formula to calculate the number of processes that must be available across the VOB server machines within a ClearCase network based on the number of VOBs to be hosted and clients to be serviced.
How many Windows VOB host servers do you need?
The number of servers required is given by the following formula:
Note: The factor for deriving the number of
db_server processes has been increased from the 1.5 estimate given earlier to 2.25. This has been done because we have elected to use one UCM project VOB for all projects. Assuming that at least one of the component VOBs in a given UCM project resides on a server other than that hosting the project VOB we think that 2.25 is a reasonable factor to use.
Views and VOBs: typical configurations
Using the formulas above, and assuming that you have 15 users, 5 VOBs and 15 views, the number of processes is less than 70, so a single server with a heap allocation of 512K would suffice for this environment. If we have 50 users, 100 VOBs, the number of process is approxiamtely 362, so to accomodate this number of processes and also have some memory for views, we must adjust our heap size to be able to run all these on a single server.
As we can see from this discussion, the number of VOBs, views, and clients running on a given Windows-based system has an effect on resource allocation. We can adjust the allocation of those resources within certain limits by adjusting the heap size to improve performance or accomodate more processes, but it is important to be aware of the limitations of the heap size when considering scaling your ClearCase environment, and when running additional applications or processes on your ClearCase servers.
- Browse for books on these and other technical topics at the Safari bookstore.
- Software Configuration Management Strategies and IBM Rational ClearCase: A Practical Introduction (2nd edition, IBM Press 2005) by David Bellagio and Tom Milligan provides a comprehensive review of CM strategies and practices with a UCM focus. This second edition is the updated and expanded version of Brian White’s popular book.
Get products and technologies
- Find more resources for ClearCase users and administrators in the ClearCase area of the developerWorks Rational zone, including articles and whitepapers, plug-ins, scripts and triggers; and links to training, discussion forums, product documentation and support.
- To learn more about IBM Rational products, visit the developerWorks Rational zone. You'll find technical documentation, how-to articles, education, downloads, product information, and more.
- Find a user group in your area from the Rational Global User Group Community. Rational User Groups are independent, user-run organizations that provide an open forum to promote information exchange between customers and Rational staff.
- The ClearCase discussion forum on developerWorks is a great place to post questions and get answers about configuration management and UCM with IBM Rational ClearCase.
Dig deeper into Rational software on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Experiment with new directions in software development.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.