In short, giant LPARs can definitely be problematic. Similarly, too small LPARs can be problematic. Somewhere in the middle is ideal, but where that is will depend.
First off, the most significant impact is you don't want LPARs whose processor count is so high that it crosses drawers. (In most cases this count would be zIIP + GP.) So that's a high water mark you definitely want to avoid that's around the low 30s for relatively recent machines. Similarly you don't want LPARs with so much memory that they cross drawers, although that may be slightly less problematic. In both cases, if you have CPs referencing memory or L4 cache on another drawer, access times will be longer. How big the impact will be depends on how much of that cross-drawer access is going on. Secondly, there's internal housekeeping and locks and latches that are impacted by having more CPs. How much this impacts things depends again on the workload. In contrast, more LPARs does add more MSU consumption for certain system tasks like monitors and the like. I.E. add an extra LPAR and it's an extra RMF/CMF that's running collecting/writing data. And extra whatever other monitors you have. And while adding a third system to the sysplex adds nowhere near the overhead that adding a second adds, there still can be some. E.G. resolving lock contention now involves potentially 3 systems instead of 2. So I wouldn't look to add systems willy-nilly where I have a sysplex of lots of small LPARs, all that are part of a single data sharing group. (I'm less concerned about adding dev/test LPARs that have minimal sharing with the production LPARs already part of the sysplex.) My general rule of thumb, is that: <10 busy CPs I'm not concerned; more than 20 busy CPs I might start to wonder (not necessarily worry) a bit; more than a drawer, I definitely want to have a discussion about it. I'm not sure that those are perfect thresholds, and I'd generally temper that with specific details about the situation. Somebody mentioned not having enough CPs such that production LPARs can't get any high-polarity CPs. I agree that's a growing problem that we're seeing with multiple customers due to the wider steps between the sub-capacity settings on the large machines. In general, going from zero to multiple high-polarity processors for important LPARs is important, but tweaking weights to convert a medium to a high on an LPAR that already has multiple highs is probably not going to be significant. (That's the general conclusion of my GSE presentation this Thursday.) ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
