Filter
Top Products
Memory Application Examples
Memory Application ExamplesMemory Application Examples
Memory Application Examples
Configuring memory is a compromise between cost, total memory capacity, and memory bandwidth requirements. The behavior of the application must be
used to define the most-desired configuration. Some applications are sensitive to memory capacity, some are sensitive to memory bandwidth, some are
sensitive to neither. If actual application measurements are not available, the following may be used as guidelines:
Large memory (VLM) applications, in which large amounts of memory can substantially reduce I/O, may be optimized for total memory capacity and
future capacity growth. In VLM applications, the right balance might be one memory base module, with upgrade, for every two CPUs. This would
result in one memory array per CPU.
Typical commercial applications, such as transaction processing (OLTP) and multi-user timesharing, usually operate efficiently from cache and may not
be materially affected by memory bandwidth. Memory configuration is a balance between memory bandwidth and future capacity growth. It is
advisable to match the number of arrays to the number of CPUs.
Data mining can benefit from additional memory bandwidth. It is best to match the number of memory base modules to the number of CPUs.
The most demanding high-performance technical applications (HPTC) achieve a performance level that is directly proportional to memory bandwidth.
In these cases, configure one memory base module, with upgrade, per CPU. This results in two memory arrays per CPU.
The following table represents how 8 GB could be configured in a 4-CPU QBB in each of the four referenced applications. The numbers under each
application represent how many of each memory option would be ordered.
Memory Configuration Examples
Memory Configuration ExamplesMemory Configuration Examples
Memory Configuration Examples
– Configuring a QBB with a total of 8 GB for specific applications
Application
ApplicationApplication
Application
VLM
OLTP, Timesharing
Data Mining
HPTC
1-GB base module
(3X-MS8AA-BB)
- - -
4
1-GB upgrade
(3X-MS8AA-BU)
- - -
4
2-GB base module
(3X-MS8AA-CB)
2 2 4
-
2-GB upgrade
(3X-MS8AA-CU)
2 2
- -
The following additional configuration options utilizing the 4-GB base module are available:
4-GB base module
(3X-MS8AA-DB)
2 2
N/R N/R
4-GB upgrade
(3X-MS8AA-DU)
- -
NOTE:
NOTE: NOTE:
NOTE:
N/R = Not recommended - For these applications, configure either four or eight like-sized memory options rather than one or two.
Step 5 - Evaluate Configuration Requirements to Support Optional Partitioning
Step 5 - Evaluate Configuration Requirements to Support Optional PartitioningStep 5 - Evaluate Configuration Requirements to Support Optional Partitioning
Step 5 - Evaluate Configuration Requirements to Support Optional Partitioning
Configuration Requirements for Partitions
Configuration Requirements for PartitionsConfiguration Requirements for Partitions
Configuration Requirements for Partitions
Configuring partitions requires some attention to detail with respect to minimum requirements for option selection, population, and option placement.
A single AlphaServer GS320 can be divided into logical hardware partitions, each running an instance of Tru64 UNIX or an instance of OpenVMS.
Each partition is allocated its own dedicated "shared-nothing" set of hardware resources: QBB(s), CPU module(s), memory module(s), and I/O.
Multiple-QBB hard partitions within a GS server do not provide complete hardware failure isolation across hard partitions. Single hard partitioned
QBBs within the server do provide hardware failure isolation.
Each hardware partition is viewed as a unique node, from a system point-of-view, with its own instance of Tru64 UNIX or OpenVMS operating system
and application software, independent system console, and error log.
Hardware partitions are defined on QBB boundaries; each partition is an integer multiple of QBBs.
Up to six hardware partitions are supported on GS320 Model 24 systems; up to eight hardware partitions are supported on Model 32 systems
One system management console (3X-DS8BA-xx or 3X-DS8DA-xx) and one console hub (3X-DS8AA-AA) are recommended per system.
Supported option rules apply for maximum configurations of each AlphaServer GS320 system partition. Care must be exercised to ensure that any
planned reconfiguration of hardware partitions will not violate option support rules.
Minimum Hardware Required per AlphaServer GS320 Hardware Partition
Minimum Hardware Required per AlphaServer GS320 Hardware PartitionMinimum Hardware Required per AlphaServer GS320 Hardware Partition
Minimum Hardware Required per AlphaServer GS320 Hardware Partition
QuickSpecs
HP AlphaServer GS320 (1224 MHz)
Options
DA - 11424 North America — Version 7 — August 19, 2003
Page 9