lockmgr reference information

On hosts running Windows and some versions of Linux, a lockmgr process arbitrates all access to every VOB on the host. Several lockmgr options can be modified if necessary to expedite VOB access under heavy loads.

Synopsis

lockmgr –a almd –f num –u num –q num

Options and arguments

Specifying the socket file name. Default: almd. (You must not change this default.)

–a almd
Specifies almd as the leaf name of the socket created by the lockmgr. Using any other name is not supported.
Note: To reduce chances of accidental deletion, /var/adm/rational/clearcase/almd is owned by root. If you are concerned that a user might accidentally modify this file, you can restrict write permission to root and the owners of all VOBs on the host. Any VOB owned by a user without write permission to /var/adm/rational/clearcase/almd is inaccessible.

Specifying the number of database files. Default on Windows®: 128. Default on other hosts: 256

–f num
Specifies the number of database files that can be open concurrently. Each VOB database consists of seven database files. The default startup values allow the lock manager to handle a maximum of 36 VOBs on a Linux host and 18 on a Windows host. If there are more VOBs on the host, the lock manager cannot to service requests for all of the VOBs concurrently. User response times are slower, and the db_server_log or vobrpc_server_log files includes messages of this form:

Error: Too many open databases on host (try increasing the -f argument on lockmgr command-line).

When this happens, you can either move some of the VOBs to another host or increase the value of the –f option to 7*V where V represents the number of VOBs on the host.

The –f option cannot be set higher than 1018.

Specifying the number of users. Default on Windows: 128. Default on other hosts: 256

–u num
Specifies the maximum number of simultaneous db_server or vobrpc_server processes running on the host. Each active view requires one vobrpc_server process for each VOB that the view accesses. In addition, various operations that change VOB metadata cause a db_server process to access the VOB through the lock manager. Poor user response time and messages of this form in the db_server_log or vobrpc_server_log files might indicate that the value of the –u option should be raised.:

db_VISTA database -922: lockmgr is busy

The –u option cannot be set higher than 1018.

You can compute a very approximate worst case value for –u by using this formula:

V*(N + 5)

In this formula, V is the number of VOBs on the host and N is the number of users who access those VOBs.

For a more realistic value (one that does not cause the lock manager to consume unnecessary virtual memory on the VOB server host) monitor the total number of db_server and vobrpc_server processes running on the VOB server host for an extended period of typical use (perhaps a week or two). Then multiply the peak value by a factor that can accommodate growth (two, or perhaps a little more).

Specifying the size of the request queue. Default on Windows: 128. Default on other hosts: 1024.

–q num
Specifies the number of lock requests for locks to be queued. The lock manager delays queuing lock requests in excess of this value. Poor user response time and messages of the form

db_VISTA database -922: lockmgr is busy

in the db_server_log or vobrpc_server_log files (and, often, concurrent timeout errors in a view_log file) may indicate that the value of the –q option should be raised. As a rule, this value should be no greater that five times the value of the –u option.


Feedback