skip book previous and next navigation links
go up to top of book: HP OpenVMS Alpha Partitioning and Galaxy Guide HP OpenVMS Alpha Partitioning and Galaxy Guide
go to previous page: Developing OpenVMS Galaxy Programs Developing OpenVMS Galaxy Programs
go to next page: OpenVMS NUMA AwarenessOpenVMS NUMA Awareness
end of book navigation links

3NUMA Implications on OpenVMS Applications  



NUMA (nonuniform memory access) is an attribute of a system in which access time to any given physical memory location is not the same for all CPUs. Given this architecture, you must have consistently good location (but not necessarily 100 percent of the time) for high performance.

The operating system treats the hardware as a set of resource affinity domains (RADs). A RAD is the software grouping of physical resources (CPUs, memory, and I/O) with common access characteristics. On the AlphaServer GS80/160/320 systems, a RAD corresponds to a quad building block (QBB); on AlphaServer ES47/ES80/GS1280 systems, a RAD corresponds to a two-processor CPU board. CPUs access memory in their own RAD faster than they access memory in another RAD.

If OpenVMS is running on the resources of a single RAD, then there is no NUMA effect and this discussion does not apply. Whenever possible and practical, you can benefit by running in a single RAD, which eliminates the complexities NUMA may present.

The most common question for overall system performance in a NUMA environment is, "uniform for all?" or "optimal for a few?" In other words, do you want all processes to have roughly equivalent performance, or do you want to focus on some specific processes and make them as efficient as possible? Whenever a single instance of OpenVMS runs on multiple RADs (whether it is the entire machine, a hard partition, or a Galaxy instance), then you must answer this question, because the answer dictates a number of configuration and management decisions you need to understand.

The OpenVMS default NUMA mode of operation is "uniform for all." Resources are assigned so that over time each process on the system has, on average, roughly the same performance potential.

If "uniform for all" is not what you want, you must understand the interfaces available to you in order to achieve the more specialized "optimal for a few" or "dedicated" environment. Processes and data can be assigned to specific resources to give them the highest performance potential possible.

To further enhance your understanding of the NUMA environment, this chapter discusses the following topics:

skip links to sections within this chapter.
OpenVMS NUMA Awareness
Application Resource Considerations
Batch Job Support for NUMA Resource Affinity Domains
RAD Application Programming Interfaces
RAD System Services Summary Table
RAD DCL Command Summary Table
System Dump Analyzer (SDA) Support for RADs
end of content navigation links


go to previous page: Developing OpenVMS Galaxy Programs Developing OpenVMS Galaxy Programs
go to next page: OpenVMS NUMA AwarenessOpenVMS NUMA Awareness