Tuning HADB
The log records remain in the buffer until they are processed locally and shipped to the mirror node. The log records are kept until the outcome (commit or abort) of the transaction is certain. If the HADB node runs low on tuple log, the user transactions are delayed, and possibly timed out.
Tuning LogBufferSize
Begin with the default value. Look for HIGH LOAD informational messages in the history files. All the relevant messages will contain tuple log or simply log, and a description of the internal resource contention that occurred.
Under normal operation the log is reported as 70 to 80% full. This is because space reclamation is said to be “lazy.” HADB requires as much data in the log as possible, to recover from a possible node crash.
Use the following command to display information on log buffer size and use:
hadbm resourceinfo
For example, output might look like this:
Node No. | Avail | Free Size |
0 | 44 | 42 |
1 | 44 | 42 |
The columns in the output are:
■Node No.:The node number.
■Avail: Size of buffer, in megabytes.
■Free Size: Free size, in MB, when the data volume is larger than the buffer. The entire buffer is used at all times.
Change the size of the log buffer with the following command:
hadbm set LogbufferSize
This command restarts all the nodes, one by one, for the change to take effect. For more information on using this command, see “Configuring HADB” in Sun GlassFish Enterprise Server 2.1 High Availability Administration Guide.
InternalLogbufferSize
The node internal log (nilog) contains information about physical (as opposed to logical, row level) operations at the local node. For example, it provides information on whether there are disk block allocations and deallocations, and
112 | Sun GlassFish Enterprise Server 2.1 Performance Tuning Guide • January 2009 |
