Tuning HP Tru64 UNIX V5.1A and V5.1B for Oracle

9
The sum of rad_gh_regions[*] should be set to the size of the Oracle SGA; however, you may
consider allocating a larger value for rad_gh_regions in order to be able to resize the Oracle
SGA without having to reboot the system; rad_gh_regions is not a dynamic system tunable
parameter so any changes will require a system reboot). Setting rad_gh_regions to a larger
value than initially required or calculated can provide the benefit of being able to allocate a larger
SGA without having to reboot the system.
Try to allocate shared memory in striped mode in order to distribute memory across all available
RADs. Changing to a sequential allocation policy may adversely affect performance as this may
cause hot spots in individual RADs. When NUMA mode is enabled in Oracle, it will itself select the
correct attributes for the allocation policy.
Generic Subsystem
Modify the following tunable parameters in the respective section(s) of /etc/sysconfigtab.
sched_distance
On EV7 based systems such as the AlphaServer ES47, ES80, and GS1280, HP recommends
allowing the system to have more freedom when scheduling processes. Setting the kernel parameter
sched_distance = 3 allows a process to be scheduled on a CPU that is up to two hops away
from its home RAD.
cpus_in_rad
For Tru64 UNIX V5.1B-3 with PK5 Service PAK a new parameter is available that lets a system
administrator change the software NUMA boundaries on EV7 based systems (AlphaServer ES47,
ES80, or GS1280). If this parameter is changed from its default value, you must apply the patches
described in the Tru64 UNIX/TruCluster Server V5.1B-3 with PK5 Service PAK section.
HP recommends that you keep this parameter at its default value of 0.
For more information about configuring the cpus_in_rad parameter, refer to the Configuring Tru64
UNIX for Large Memory Applications in a NUMA Environment white paper:
http://h30097.www3.hp.com/pdf/numa-2.pdf
AdvFS Subsystem
Modify the following tunable parameters in the advfs subsystem section of /etc/sysconfigtab.
AdvfsSyncMmapPages
This parameter controls how AdvFS flushes dirty mmap()’d pages using the sync() system call.
Since most applications that use mmap() to map pages/files into memory are using their own
synchronization through the fsync() call, there is rarely a need for AdvFS to perform the same
operation again.
Setting AdvfsSyncMmapPages = 0 will prevent AdvFS from trying to flush pages of files that have
been mmap()’d and will also avoid AdvFS trying to flush pages that should be left memory resident;
this is often seen in Oracle 9i Application Server environments.
Setting this parameter to the default value of 1 will cause memory mapped pages to be written
asynchronously to disk during a sync() system call.
The recommended value for AdvfsSyncMmapPages is 0.