23.10.2014 Views

Advanced POWER Virtualization on IBM System p5 - Previous ...

Advanced POWER Virtualization on IBM System p5 - Previous ...

Advanced POWER Virtualization on IBM System p5 - Previous ...

SHOW MORE
SHOW LESS

Create successful ePaper yourself

Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.

The following rules of thumb should be c<strong>on</strong>sidered when c<strong>on</strong>figuring the number<br />

of virtual processors in shared-processor partiti<strong>on</strong>s:<br />

►<br />

►<br />

►<br />

►<br />

The number of virtual processors in a shared-processor partiti<strong>on</strong> should not<br />

exceed the number of physical processors in the shared-processor pool.<br />

The number of virtual processors in a capped shared-processor partiti<strong>on</strong><br />

should not exceed the entitlement rounded up to the nearest whole number.<br />

For versi<strong>on</strong>s of AIX 5L prior to V5.3 Maintenance Level 3 or with later versi<strong>on</strong>s<br />

of AIX 5L with the virtual processor folding feature disabled, the sum of all the<br />

virtual CPUs in all active shared-processor partiti<strong>on</strong>s should not be greater<br />

than four times the number of physical processors in the shared-processor<br />

pool.<br />

For versi<strong>on</strong>s of AIX 5L after Versi<strong>on</strong> 5.3 ML3 with virtual processor folding, an<br />

excessive virtual CPU count has a very low performance impact.<br />

Capped or uncapped partiti<strong>on</strong>s?<br />

Capped partiti<strong>on</strong>s will never exceed their entitlements, even if they are<br />

overloaded and there are unused resources in the system. Generally, the use of<br />

capped partiti<strong>on</strong>s is to be discouraged; use uncapped partiti<strong>on</strong>s and prioritize the<br />

allocati<strong>on</strong> of spare capacity using partiti<strong>on</strong> weights.<br />

5.6.2 <str<strong>on</strong>g>Virtualizati<strong>on</strong></str<strong>on</strong>g> and applicati<strong>on</strong>s<br />

Some applicati<strong>on</strong>s and middleware products are not able to adapt to dynamic<br />

rec<strong>on</strong>figurati<strong>on</strong> changes, for example, the product starts a number of processes<br />

based <strong>on</strong> the number of c<strong>on</strong>figured processors. If the applicati<strong>on</strong> requires more<br />

computing power, adding additi<strong>on</strong>al processors will not have any effect without<br />

shutting down the applicati<strong>on</strong> and restarting it. Using shared processors, it is<br />

possible to change the entitlement of virtual processors to change the processing<br />

resources available to the applicati<strong>on</strong>. Because the processor count does not<br />

change, then applicati<strong>on</strong>s that are not DR aware do not have to be restarted.<br />

If an applicati<strong>on</strong> or workload envir<strong>on</strong>ment is cache sensitive or cannot tolerate<br />

the variability introduced with resource sharing, it should be deployed in a<br />

dedicated processor partiti<strong>on</strong> with SMT disabled. In dedicated partiti<strong>on</strong>s, the<br />

entire physical processor is assigned solely to the partiti<strong>on</strong>.<br />

5.6.3 Resource management<br />

PLM and WLM provide resource and workload management. Some applicati<strong>on</strong>s<br />

and middleware also provide their own resource management and in particular<br />

databases. Care should be taken when using the resource management tools in<br />

AIX 5L and the <str<strong>on</strong>g>POWER</str<strong>on</strong>g> Hypervisor with such applicati<strong>on</strong>s and middleware.<br />

Chapter 5. <strong>System</strong> management 357

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!