Server User Manual
Table Of Contents
- Sun GlassFish Enterprise Server 2.1 Performance Tuning Guide
- Preface
- Overview of Enterprise Server Performance Tuning
- Tuning Your Application
- Java Programming Guidelines
- Java Server Page and Servlet Tuning
- EJB Performance Tuning
- Goals
- Monitoring EJB Components
- General Guidelines
- Using Local and Remote Interfaces
- Improving Performance of EJB Transactions
- Use Container-Managed Transactions
- Don’t Encompass User Input Time
- Identify Non-Transactional Methods
- Use TX_REQUIRED for Long Transaction Chains
- Use Lowest Cost Database Locking
- Use XA-Capable Data Sources Only When Needed
- Configure JDBC Resources as One-Phase Commit Resources
- Use the Least Expensive Transaction Attribute
- Using Special Techniques
- Tuning Tips for Specific Types of EJB Components
- JDBC and Database Access
- Tuning Message-Driven Beans
- Tuning the Enterprise Server
- Deployment Settings
- Logger Settings
- Web Container Settings
- EJB Container Settings
- Java Message Service Settings
- Transaction Service Settings
- HTTP Service Settings
- ORB Settings
- Thread Pool Settings
- Resources
- Tuning the Java Runtime System
- Tuning the Operating System and Platform
- Tuning for High-Availability
- Index
Note – hadbm does not add data devices to a running database instance.
Placing HADB les on Physical Disks
For best performance, data devices should be allocated on separate physical disks. This applies if
there are nodes with more than one data device, or if there are multiple nodes on the same host.
Place devices belonging to dierent nodes on dierent devices. Doing this is especially
important for Red Hat AS 2.1, because HADB nodes have been observed to wait for
asynchronous I/O when the same disk is used for devices belonging to more than one node.
An HADB node writes information, warnings, and errors to the history le synchronously,
rather than asynchronously, as output devices normally do. Therefore, HADB behavior and
performance can be aected any time the disk waits when writing to the history le. This
situation is indicated by the following message in the history le:
BEWARE - last flush/fputs took too long
To avoid this problem, keep the HADB executable les and the history les on physical disks
dierent from those of the data devices.
Memory Allocation
It is essential to allocate sucient memory for HADB, especially when it is co-located with other
processes.
The HADB Node Supervisor Process (NSUP) tracks the time elapsed since the last time it
performed monitoring. If the time exceeds a specied maximum (2500 ms, by default), NSUP
restarts the node. The situation is likely when there are other processes in the system that
compete for memory, causing swapping and multiple page faults. When the blocked node
restarts, all active transactions on that node are aborted.
If Enterprise Server throughput slows and requests abort or time out, make sure that swapping
is not the cause. To monitor swapping activity on Unix systems, use this command:
vmstat -S
In addition, look for this message in the HADB history les. It is written when the HADB node
is restarted, where M is greater than N:
Process blocked for .M. sec, max block time is .N. sec
The presence of aborted transactions will be signaled by the error message
HADB00224: Transaction timed out or HADB00208: Transaction aborted.
Tuning HADB
Chapter 6 • Tuning for High-Availability 109