Understanding Micro-Partitioning

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.

Again, in configuring an LPAR, a minimum/desired/maximum value must be set for the number of virtual processors. These values serve strictly as boundaries for dynamic LPAR operation while varying the number of virtual processors on a running LPAR.

From Dedicated to Shared

Still today, a very large number of customers are running LPARs in a dedicated mode. A question I often get is: What's the best way to convert an LPAR from a dedicated mode to a shared uncapped mode without affecting performance? The simplest way is to just change its mode from dedicated to shared uncapped and make sure the number of virtual processors are equal to the entitled capacity. By doing so, the LPAR will preserve its entitled capacity, which is its guaranteed cycles. Its entitled capacity being guaranteed will ensure this LPAR can’t starve and application response time isn’t impacted. The immediate advantage is any unused CPU cycles from that LPAR will go from wasted (dedicated mode) to yielded back to the shared processor mode (shared uncapped) and readily available for any other LPAR that might need it. A second step is to look at the LPAR's CPU consumption and determine if it could use more CPU. If the LPAR does show signs of plateauing at 100 percent, then adjusting the number of virtual processors up (one virtual processor at a time) will allow that LPAR to borrow cycles from other LPARs that might not be using their full entitlement.

There are a few important considerations when implementing this very simple method. If your LPAR now uses more then its entitled capacity, it’ll report more then 100 percent CPU utilization. That can result in issues with some performance-monitoring software and make some people uneasy. The other consideration is users might have varying application response times at different times of day, based on the available CPUs in the processor pool. If your processor pool reaches full utilization, applications using more then their entitled capacity might have their response time return dedicated-like performance. Fortunately, this isn’t often the case. If you haven’t enabled processor pooling in your configuration, give it a try; you'll be surprised just how much free CPU you’ll end up with.

Optimizing Pooled Resources

Over the years, I've developed a very simple approach to getting the most out of micropartitioned environments. This approach is based on a good understanding of entitled capacity. In maximizing a system's utilization, you'll want to drive each LPAR's utilization as close as possible to 100 percent, on average. Once an LPAR has been converted from being dedicated to being shared uncapped, you’ll want to gradually reduce its entitled capacity so it reports higher utilization until your LPAR's average utilization is at a level you feel comfortable with. Your LPAR's peaks, more then likely, will exceed the LPAR's entitled capacity (100 percent), and that's fine. If all of your LPARs on your managed systems run at 90 percent utilization on average, and all your entitled capacity is dispatched, then your entire managed system will be running at 90 percent utilization.

One very important factor in determining the average utilization you wish to have on your LPAR is the managed system size. The larger the system, the more LPAR on the system, the higher the utilization target can be set. This is simply a reflection of the law of large numbers in probability theory.