Windows and the ClearCase process limit: Understanding the desktop heap

How to allocate memory resources for ClearCase processes on Windows-based systems

Understanding the Windows desktop heap is important when considering how to allocate memory resources for Windows-based ClearCase VOB and View servers.

Share:

Introduction

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:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\Session Manager\SubSystems\Windows

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:

memory use per process

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.

process per view

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.

servers required per number of hosted views

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.

processes per vobs plus clients

How many Windows VOB host servers do you need?

The number of servers required is given by the following formula:

servers needed per vobs plus clients

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.

Resources

Learn

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.

Discuss

  • 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.

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Rational software on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Rational
ArticleID=100679
ArticleTitle=Windows and the ClearCase process limit: Understanding the desktop heap
publish-date=12202005