When setting up CPU pools, pay attention to the physical server architecture.
Larger servers with a higher multiprocessor level have multiple process modules. These generally have their own cache. In NUMA architectures, each module is also assigned part of the main memory from an administration perspective. Access by a CPU core to the main memory of its “own” process module has a higher performance than access to “more remote” memory modules.
If a task or a VM moves between different process modules during processing, the performance is impaired by cache losses and memory access times. When using CPU pools, you have the opportunity to reduce these effects:
- Only assign CPUs from the same processor module to your CPU pools:
In an optimum situation, each CPU pool will be limited to just one module.
However, such strict delineation is not always possible, e.g. as soon as a CPU has to have more CPUs than a single module provides due to the performance requirements of a VM. You should then attempt to distribute your CPU pools among the CPUs in such a way that- at least the most performance critical VMs can use as many CPUs as possible from a particular module.
- as few CPU pools as possible are split between multiple modules.
The general conditions to be observed depend on the relevant server unit:
SU /390
An SU /390 has one or two system boards. These each house a processor module with up to 8 BS2000 CPUs and the associated IO processors and main memory.
An SU500(B) has only one system board.
An SU700(B) or SE710 has one to two system boards.
Up to and including SU700(B)-70 or SE710-70, all CPUs are located on one board, which means there is nothing to be concerned about.
The SU700(B)-100 to SU700(B)-160 and SU710-100 to SU710-160 models have two system boards. The first 8 CPUs are located on the first board and all others on the second board. Ideally, your CPU pools should therefore cover only the CPUs 0-7 or 8-15.
SU x86
An SU x86 has two or four Intel processors. Each of these correspond to a processor module. To guarantee thorough separation, CPU pools exist at several hierarchical levels, some of which cannot be influenced by configuration settings.
More in-depth details can be found in the “SE700 / SE500 / SE300- Administration and Operation” manual[28 (Related publications)], “Visualization on x86 server unit” section. To understand this, the following information is relevant:
Each physical CPU (corresponding to an Intel core) is pre-assigned to one of three internal system pools (X2000, BS2000, Xen-VM). This classification cannot be influenced.
The pool containing all BS2000 CPUs is located in one or two process modules depending on the number of CPUs. Under VM2000, a further subdivision can be carried out using VM2000 CPU pools.
From a VM2000 perspective, the assignment of the physical CPUs therefore follows essentially the same logic as for /390 servers, i.e. the first BS2000 CPU is always assigned to the first CPU in a particular module. If there are more BS2000 CPUs than a module provides, all remaining CPUs are located in one other module. The following applies here:
An SU300 has Intel processors, each with 12 cores. Ideally, your CPU pools should therefore cover only the BS2000 CPUs 0-11 or 12-15.
An SU300B has Intel processors, each with 18 cores. Therefore all BS2000 CPUs are located in the same module.
- An SU310 has Intel processors, each with 16 cores. Therefore all BS2000 CPUs are located in the same module.