HP-UX 11i v3 Memory Management Subsystem

14
Configuration and tuning opportunities
HP-UX aims to be simple to use. Its behavior straight out of the box should be completely satisfactory for most uses,
with no need to perform manual configuration or tuning. However, both the size of the host servers and the
workloads imposed upon them vary widely across the range of scenarios in which HP-UX is deployed. For
example, system memory size can be as small as 1.5 GB or as large as 8 TB. Applications may create thousands
of transient processes that manipulate small messages, or they may have a modest number of long-lived processes
that access huge data structures. The HP-UX solution is to offer solid out-of-the-box defaults, but to provide the
means to perform fine tuning. This section gives some guidance if tuning is desired.
Local memory versus interleaved memory
HP servers with NUMA (non-uniform memory access) are structured as a complex of modular building blocks each
containing memory local to the physical component. When an nPartition (a hardware partition featuring both
electrical and operating system isolation) is formed from multiple components, any or all of the memory in the
partition can be interleaved. Interleaving, which is effected through the
parcreate(1M) or parmodify(1M)
command, distributes memory references evenly across all involved localities. Interleaving is established at the
granularity of a cacheline, which is the quantum of data for communication between processors and memory.
Memory not chosen to be interleaved remains as local memory, which can be accessed much more quickly by
processor cores that reside in the same locality.
For most commercial applications, the sweet spot is a memory configuration with the ratio
7
/
8
local memory to
1
/
8
interleaved memory. Workloads exhibiting no locality of memory reference, such as certain technical applications,
might do better with 100% interleaved memory, but the recommended
7
/
8
to
1
/
8
ratio is a good starting point for
commercial applications.
A program such as locinfo reveals the relative utilization of the various memory localities. If the interleaved
locality is significantly over-utilized or under-utilized, it might be appropriate to change the interleaved memory ratio
through the
parmodify command. This requires a reboot to take effect, so should be performed only if it is
acceptable to reboot the nPartition.
In a vPars environment, the vPars instances can be built from local memory if the underlying nPartition was so
configured. Any virtual partition that contains memory from more than one locality should also include interleaved
memory, with
1
/
8
of the total memory in the instance being the suggested amount. A virtual partition that contains
resources from only one locality need not have any interleaved memory at all.
Ejectable (floating) memory
HP-UX supports dynamic platform reconfiguration: physical resources such as entire cell boards or memory ranges
can be online activated or deactivated without interrupting the application workload. A cell board that can be
online deactivated is called a floating cell; one that cannot be deactivated without a reboot is called a base cell. In
a vPars context, a memory range that can be online deactivated is called ejectable or floating; one that cannot be
deactivated without a reboot is called non-ejectable or base.
The designation of a cell as base or floating is accomplished via the parcreate or parmodify command. The
designation of vPars memory as base or floating is accomplished via the
vparcreate or vparmodify command.
On HP Superdome 2 platforms, these operations can also be performed through the Onboard Administrator.
The HP-UX memory management subsystem never places certain kernel data structures in floating memory. This
important optimization allows the kernel to perform smoothly during dynamic platform reconfiguration events. The
consequence is that the kernel can be starved for memory on a platform configured with too little base memory.
The minimum requirement is to keep at least 25% of memory as base memory. Smaller systems (around 2 GB of
memory) may require more than the minimum; larger systems can operate at the minimum comfortably. The
locinfo program can be used to determine the relative utilization of base and floating memory. If a system is
starved for base memory but has excess floating memory, it is possible to deactivate some of the floating memory
and then reactivate it as base memory, avoiding the need to reboot the system.