Micro-Partitioning was introduced as a feature of the POWER5 processor-bad product line back in 2004, yet I still get a number of questions on a regular basis around implementing and understanding Micro-Partitioning. In this article, I'll try and paint a concise and clear picture of everything you need to know about Micro-Partitioning in the Power Systems environment and address the most frequently asked questions with regards to best practices. Every reference I'll be making throughout this article will be in the context of shared uncapped LPARs.
Understanding Entitled Capacity
The entitled capacity of an LPAR plays a crucial role. It determines two very important factors: the guaranteed CPU cycles the LPAR will get at any point in time, and the base unit of measurement for utilization statistics. One aspect of a managed system's entitled capacity is that the total entitled capacity on the system cannot exceed the number of physical processors in that system. In plain English: the system's processors can not be over-subscribed by the total of the entitlements. As a side effect, this means every LPAR on a managed system will always be able to use its entitled capacity at any point in time. This capacity is guaranteed to be available to its LPAR within one dispatch cycle (10ms).
On the other hand, if an LPAR isn’t making full use of its entitlement, these cycles are being yielded back to the shared processor pool that LPAR is part of. The second crucial aspect of entitled capacity is being the basis for utilization statistics and performance reporting. Ore more simply: an LPAR consuming all of its entitled CPU capacity will report 100 percent utilization. Now that LPAR will not necessarily be limited to 100 percent utilization. Depending on that LPAR's virtual-processor configuration, it'll be able to borrow unused cycles from the shared processor pool and report more then 100 percent utilization. In that case, it’s important to know that any capacity used beyond an LPAR's entitled capacity isn’t guaranteed (as it might be some other LPAR's entitlement). Therefore, if an LPAR is running beyond 100 percent CPU, it might be forced back down to 100 percent if another LPAR requires that borrowed capacity.
Then why is there a minimum/desired/maximum setting for entitlement? Because the entitled capacity of an LPAR can be changed dynamically. The minimum and maximum values of entitled capacity are there to set the limits to which a running LPAR's entitled capacity may be varied.
The Role of Virtual Processors
Virtual processors are what AIX sees as being actual CPUs from an OS standpoint. You have to look at them as being a logical entity that is backed up by physical processor cycles. For each virtual processor, between 0.1 and 1.0 physical processor can be dispatched to execute tasks in that virtual processor's run queue. There are no conditions under which a single virtual processor will consume more then 1.0 physical processor. Therefore, the number of online virtual processors dictates the absolute maximum CPU consumption an LPAR can achieve (should enough capacity be available in its shared processor pool). That being said, if an LPAR has an entitlement of 2.0 processors and four virtual processors, this LPAR could be able to consume up to four physical processors, in which case, it will report 200 percent CPU utilization. You must keep in mind, while configuring virtual processors on a system, it’s possible to dispatch more virtual processors then there are physical processors in the shared processor pool, therefore you might not be able to have an LPAR peak all the way up to its number of virtual processors.
Like what you just read? To receive technical tips and articles directly in your inbox twice per month, sign up for the EXTRA e-newsletter here.