The HADB stores data on data devices, which are allocated on disks. The data must be in the main memory before it can be processed. The HADB node allocates a portion of shared memory for this purpose. If the allocated database buffer is small compared to the data being processed, then disk I/O will waste significant processing capacity. In a system with write-intensive operations (for example, frequently updated session states), the database buffer must be big enough that the processing capacity used for disk I/O does not hamper request processing.
The database buffer is similar to a cache in a file system. For good performance, the cache must be used as much as possible, so there is no need to wait for a disk read operation. The best performance is when the entire database contents fits in the database buffer. However, in most cases, this is not feasible. Aim to have the “working set” of the client applications in the buffer.
Also monitor the disk I/O. If HADB performs many disk read operations, this means that the database is low on buffer space. The database buffer is partitioned into blocks of size 16KB, the same block size used on the disk. HADB schedules multiple blocks for reading and writing in one I/O operation.
Use the hadbm deviceinfo command to monitor disk use. For example, hadbm deviceinfo --details will produce output similar to this:
NodeNo TotalSize FreeSize Usage 0 512 504 1% 1 512 504 1%
The columns in the output are:
TotalSize: size of device in MB.
FreeSize: free size in MB.
Usage: percent used.
Use the hadbm resourceinfo command to monitor resource usage, for example the following command displays data buffer pool information:
%hadbm resourceinfo --databuf NodeNo Avail Free Access Misses Copy-on-write 0 32 0 205910260 8342738 400330 1 32 0 218908192 8642222 403466
The columns in the output are:
Avail: Size of buffer, in Mbytes.
Free: Free size, when the data volume is larger than the buffer. (The entire buffer is used at all times.)
Access: Number of times blocks that have been accessed in the buffer.
Misses: Number of block requests that “missed the cache” (user had to wait for a disk read)
Copy-on-write: Number of times the block has been modified while it is being written to disk.
For a well-tuned system, the number of misses (and hence the number of reads) must be very small compared to the number of writes. The example numbers above show a miss rate of about 4% (200 million access, and 8 million misses). The acceptability of these figures depends on the client application requirements.
To change the size of the database buffer, use the following command:
hadbm set DataBufferPoolSize
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 Java System Application Server Enterprise Edition 8.2 High Availability Administration Guide.