Performance Tuning for Content Manager

224 Performance Tuning for Content Manager

To update

Run the following DB2 command:

db2 update db cfg for <database name> using LOGBUFSZ <parameter value>

Our recommendation

Start with the default. Increase the size of this buffer area if there is considerable

read activity on a dedicated log disk, or there is high disk utilization.

When increasing the value of this parameter, you should also consider increasing

the DBHEAP parameter because the log buffer area uses space controlled by

DBHEAP.

You can use the database system monitor to determine:

 Maximum total log space used (TOT_LOG_USED_TOP): The maximum

amount of total log space used (in bytes). This value includes space used in

both the primary and secondary log files.

 Unit of work log space used (UOW_LOG_SPACE_USED): Log buffer space

used for a particular transaction (or unit of work).

8.6.19 Maximum storage for lock list (LOCKLIST)

Impact

DB - High

Description

This parameter indicates the maximum amount of storage that is allocated to the

lock list. There is one lock list per database and it contains the locks held by all

applications concurrently connected to the database. Locking is the mechanism

that the database manager uses to control concurrent access to data in the

database by multiple applications. Both rows and tables can be locked. The

database manager may also acquire locks for internal use.

On 32-bit platforms, each lock requires 36 or 72 bytes of the lock list, depending

on whether other locks are held on the object:

 72 bytes are required to hold a lock on an object that has no other locks held

on it.

 36 bytes are required to record a lock on an object that has an existing lock

held on it.

Chapter 8. Tuning DB2 for Content Manager 225

On 64-bit platforms, each lock requires 56 or 112 bytes of the lock list, depending

on whether other locks are held on the object:

 112 bytes are required to hold a lock on an object that has no other locks held

on it.

 56 bytes are required to record a lock on an object that has an existing lock

held on it.

When the percentage of the lock list used by one application reaches

MAXLOCKS, the database manager will perform lock escalation, from row to

table, for the locks held by the application (described below). Although the

escalation process itself does not take much time, locking entire tables (versus

individual rows) decreases concurrency, and overall database performance might

decrease for subsequent accesses against the affected tables.

When the lock list is full, performance can degrade because lock escalation will

generate more table locks and fewer row locks, thus reducing concurrency on

shared objects in the database. Additionally, there could be more deadlocks

between applications (because they are all waiting on a limited number of table

locks), which results in transactions being rolled back. An application gets -912

when the maximum number of lock requests has been reached for the database.

Default values (range)

100 (4 - 524,288) 4-KB pages for UNIX

50 (4 - 524,288) 4-KB pages for Windows database with local and remote clients

50 (4 - 60,000) 4-KB pages for Windows 64-bit database server with local clients

25 (4 - 60,000) 4-KB pages for Windows 32-bit database server with local clients

To update

Run the following DB2 command:

db2 update db cfg for <database name> using LOCKLIST <parameter value>

Our recommendation

The Content Manager installation program changes this value to 1000 for both

the Library Server and the Resource Manager databases.

Initially, use these default values. Use the snapshot command to monitor your

databases. Keep an eye on the LOCK_ESCALS (lock escalations) monitor

element. If you are having problems with lock escalation, you might need to

increase the value of this parameter or the MAXLOCKS parameter.