Managed Systems can become suboptimal in terms of processor and memory affinity when reassigning or moving resources. For example DLPAR operations, LPM and LPAR creation/deletion can cause that some CPU and RAM assignemts of an LPAR are in different chips or CECs, so reaching out to these resources takes longer.
Memory locations can be:
- Local: Memory that is directly attached to the processor of the LPAR (same chip)
- Near: Memory that is within the same node/drawer (CEC) as the processor using it (other chip, but same CEC)
- Far: Memory in other nodes/drawers (CEC) (other CEC)
Local is the best and that is the aim of DPO.
In smaller systems (S922, S924, E950) there is no near, if it is not local memory access then it will go through a "far" path". Near memory access has a meaning on servers with multiple CECs (like on E980 near means other chip but same CEC drawer)
The optimal situation is when an LPAR can fit into a CPU configuration where memory access is "local". However with bigger LPARs or after many LPMs memory access can be degraded. Enhanced feature of the mpstat -d command can be used to display statistics on local, near and far memory accesses for every logical CPU in an LPAR, as presented here:
-----------------------------------
lssrad:
lssrad command displays how CPU/RAM assigned to an LPAR. (An SRAD is a group of CPU and its RAM which is directly attached to it.)
# lssrad -av
REF1 SRAD MEM CPU
0
0 40050.38 0-71
1 54281.25
(Here we have 2 SRADs (0,1) with RAM in both SRADs, but CPU is assgned only to SRAD 0. It means CPU has to reach sometimes SRAD1 for some memory, which is not optimal. DPO can rearrange this layaout.)
-----------------------------------
The Dynamic Platform Optimizer (DPO) is a PowerVM virtualization feature that improves partition memory and processor placement (affinity) on
Power servers. DPO determines an optimal RAM and CPU placement for the server based on the partition configuration and hardware topology. After that it performs memory and processor relocations to reach optimal layout. This process occurs dynamically while the partitions are running.
DPO related commands are issued in HMC command line and these provides an affinity score to determine how optimal the system affinity is and what potential affinity can be achieved, after that optimization can occur.
Requirements:
- Power Systems Firmware level 760 or later
- HMC version 7.6.0 or later
- License code for DPO. (HMC GUI -> properties of the managed system)
- At least one free Logical Memory Block (LMB) on the syst
- A DPO aware AIX is preferable (but not a requirement), so no reboot is needed after optimization (AIX 6.1 TL8/7.1 TL2 or later versions)
-----------------------------------
Check affinity (lsmemopt):
lsmemopt can list the current affinity score, and can calculate the potential affinity score which could be attained after running DPO. A system's affinity score shows how good the processor-memory affinity on the system. 0 representing the worst affinity and 100 representing perfect affinity.
You can list explicitly which partition to optimize, or you can list which partition to exclude from optimization. If neither is used all partitions are considered to optimization.
lsmemopt -m <system_name> -o currscore <--shows affinity score of managed system
lsmemopt -m <system_name> -o calcscore <--shows potential affinity score after running DPO (this is a prediction)
(these commands are safe to use, these are doing no changes on the system)
-----------------------------------
Optimization with DPO (optmem):
While an optimization is running, the performance of the partitions are degraded (memory of the partition has to be relocated.) A system with busy processors takes longer to optimize, because the background optimizer tries to minimize its effect on running partitions. (Partitions that are powered off can be optimized quickly because the contents of their memory do not need to be maintained.)
Impacted partitions can have up to 20% of performance degradation while partition memory is relocated. (However, partitions that are explicitly protected (listed as excluded partitions) from DPO are not affected.)
1. lshwres -m <system_name> -r mem --level sys -F curr_avail_sys_mem <--shows available memory (at least 1 LMB size is needed)
2. optmem -m <system_name> -t affinity -o start <--starts optimization for all LPARs on the entire system
3. lsmemopt -m <system_name> <--shows progress status as percentage completed (progress=2 means 2%)
4. lsmemopt -m <system_name> -o currscore <--check affinity score after DPO completes
If you want to specify/exclude some LPARS:
optmem -m sys -o start -t affinity -p lp1,lp3 <--start DPO only on LPAR lp1 and lp3
optmem -m sys -o start -t affinity --id 2,4,6-9,11 --xid 1 <--start DPO with partition ID 2,4,6 - 9, and 11, while excluding ID 1
optmem -m sys -o stop <--stop a DPO operation
-----------------------------------
Some considerations: If (after 'Power On' of a Managed System), you start VIOSes first and then the high important, critical LPARs then these will get the best resource locations. These probably can be omitted from optimization. It can be a good idea to check 'calcscore' from crontab every week and then send the result via email. It is probably not a good idea to automatically run an optimization on this by crontab.
No comments:
Post a Comment