First, I'm not a performance expert. Here are my thoughts.
Based on what information you have provided it would seem you are talking one CEC. The environment I last worked at we had two CECs and we did Db2 data sharing with Db2 systems spread across both CECs. From time to time, we would look at how well the CF environment was performing. Things like how busy was the CFs overall. Also, we would look to see if there any issues related to lock and buffer pool structure sizes. I'm sorry but the "it depends" really does come into play. The overall workload might determine the proper number of CPs that a given lpar might need to support the workload. When we say that its better to do 4 lpars with 8 CPs compared to 1 lpar with 32 CPs. It seems you are saying you would have a CEC with 32 general CPs. So, from what I can see you are basically dedicating the CPs to the 4 lpars. So yes, based on what I know the overhead for any given lpar for managing the 8 CPs would be less than managing all 32 CPs in one lpar. Now if the CEC does not have 32 CPs and you still want 4 lpars with 8 CPs then you start adding overhead for managing the logical to physical activity/management. Now there is overhead in a Db2 data sharing environment. The CF environment has gotten better over the years related to overall performance. How much overhead you will have is going to be determined by how busy/active the data sharing environment is. There is the CF overhead and there is the Db2 shared buffer pool management. If you have a lot of lock contention that could impact your overall Db2 performance. Also, if you are running several lpars in a sysplex that are sharing a workload you might encounter some overhead from things like WLM and GRS. This might add a little to the amount of CPU usage and CF usage. The fog of retirement is starting to set in, but I seem to remember there is an IBM tool that can be used for modeling lpar/CEC layout. I've normally saw it used for helping determine the size of a new CEC and how the lpars would be laid out. But I'm guessing you might use it to help determine a new lpar lay out for an existing CEC. Someone from IBM (or someone more familiar with the tool) might have a better answer. Paul -----Original Message----- From: IBM Mainframe Discussion List <[email protected]> On Behalf Of Radoslaw Skorupka Sent: Friday, April 19, 2024 8:06 AM To: [email protected] Subject: Re: Big LPAR vs small LPAR and DataSharing. W dniu 19.04.2024 o 10:32, Massimo Biancucci pisze: > Hi everybody, > > In a presentation at GSE I saw a slide with a graph about the > advantage of having more small sysplex LPARs versus a bigger one. > So for instance, it's better to have 5 LPARs with 4 processors than > one with 20. > > There was a sentence: "It doesn't take an extremely large number of > CPUs before a single-image system will deliver less capacity than a > sysplex configuration of two systems, each with half as many CPUs". > And: "In contrast to a multiprocessor, sysplex scaling is near linear. > Adding another system to the sysplex may give you more effective > capacity than adding another CP to an existing system." > > We've been told (IBM Labs, it seems) that a 4 ways DataSharing with 8 > CPUs perform 20% better than a single LPARs with 32 CPUs. > The same (at another customer site) with "having more than 8 CPUs in a > single LPAR is counterproductive". > > Putting these infos all together, it seems it's better to have more > small partitions (how small ???) in data sharing than, let me say, > four bigger ones (in data sharing too). > > Anybody there has direct experience on doing and measuring such scenarios ? > Mainly standard CICS/Batch/DB2 application. > Of course I'm talking about well defined LPARs with High Polarization > CPUs, so don't think about that. > > Could you imagine and share your thoughts (direct experiences would be > better) about where the inefficiency comes from ? > Excluding HW issues (Polarization and so on), could it come from zOS > related inefficiency (WLM queue management) ? > If so, do zIIP CPUs participate in inefficiency growth ? > > I know that the usual response is "it depends", anyway I'm looking for > general guidelines that allow me to choose. > > Thanks a lot in advance for your valuable time. > Max Well, it is not my problem (I use smaller configurations). However I do have some remarks: 1. Sysplex overhead. Parallel Sysplex have a lot of advantages, except one: CPU. That means it is more effective to assign 1000MSU to single LPAR than to spread it across 2 or more LPARs. 2. Parallel Sysplex history - many years ago IBM introduced new CPU technology - CMOS. However new CMOS CPs were significantly less powerful than old ECL. And there was no way to add more CPs to the CPC or LPAR. (LPAR was quite new concept at the time). So Parallel Sysplex was the only way to scale the machines. However today single CPC can have up to 200 CPs - a lot. More than you need. So scalability is no longer a problem. 3. Each multi-CP solution have some overhead, so it is never "1+1=2", it is rather "1+1=1,9". But the delta is growing with the numer of CPs, but spreading the CPs across multiple system images provide more overhead. 4. What do you prefer? 8 CPs at 100MSU each or single CP at 800MSU? 5. Everything depends on your workload. Single DB2 or bunch of CICS+VSAM applications? Single batch critical path or multiple "threads"? However for multi-application environment it is IMHO still easier to cut large CP into pieces than to aggregate multiple CPs into single CP resource for single-application. -- Radoslaw Skorupka Lodz, Poland ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] <mailto:[email protected]> with the message: INFO IBM-MAIN ---------------------------------------------------------------------- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [email protected] with the message: INFO IBM-MAIN
