Hi Tom, These systems have been a long time in creating and we rolled them out over time. It was really only after we converted the last (and most heavily used) one that we hit the 100% point at peak times and are now suffering.
Also, we went only from CICS/TS 1.1.0 to CICS/TS 1.1.1 so there isn't anything major there. I checked the frequency of dumps, nothing unusual there. It seems only when relatively heavy batch jobs are run during the peak times that we are pushed to our limits and beyond. I'm curious how you are able to run in one VSE machine with CICS/TS running with a relatively heavy batch job and not have it affect other VSEs if pushed to 100% CPU utilization? Thanks, Mike -----Original Message----- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Tom Duerbusch Sent: April 23, 2008 3:35 PM To: IBMVM@LISTSERV.UARK.EDU Subject: (LCOS: 10.6908) Re: (LCOS: 10.6908) Re: Using SET SHARE, performance problem Well, yes and no... I tend to put all partitions in a balance group and then set shares. The reason is that I don't want any batch partitions being starved of CPU. Why? We use DB2. When a batch job issues a query to DB2, which may be over an IP connection, when the results come back, the batch job MUST be able to respond within the timeout option. The same thing happens with batch FTP. But your setup looks fine. That is, CICS is given the CPU when it needs it, over any batch job. All the jobs you have running ahead of CICS, are "server" class, and really shouldn't be using that much CPU. So, it looks like CICS is using all the CPU it can get and needs more. By any chance have you looked at the console log for CICS (from FAQS d,act,f5)) and see if you are getting a lot of dumps? Also do a CEMT INQ TRDUMPCODE and CEMT INQ SYDUMPCODE. I wonder if you are getting a lot of dumps that may be using up CICS resources. Also, when you went from VSE/ESA 2.6 to z/VSE 4.1, did you pull out the new JCL from ICCF Library(59) and recustomize it? I'm wondering if you either recustomized it wrong, or didn't recustomize it and didn't notice the vast amount of changes between CICS/TS (even though they are the same releases)? I've been bit by just taking the old JCL and using it after FSU upgrades. It works, at least it tests well, but....it can be a land mine, just waiting. Tom Duerbusch THD Consulting Law of Cat Acceleration A cat will accelerate at a constant rate, until he gets good and ready to stop. >>> "Horlick, Michael" <[EMAIL PROTECTED]> 4/23/2008 2:08 PM >>> Hi Tom, This is what we have for our busiest VSE system: PRTY XCM MIKE AR 0015 PRTY G=T=P=BG=FA=F9=F7,Z,F4,F5,F6,E,F8,FB,F3,F2,F1 AR 0015 SHARE G= 100, T= 100, P= 100, BG= 100, FA= 100, F9= 100, F7= 100 F1 = Power, F2 = CA-Faqs F3 = VTAM, FB = BSM, F8 = Tmon/LSS, E = TCP/IP Telnet, F6 = CICS/TS Alternate, F5 = CICS/TS Primary, Z = Zeke, G = TCP/IP batch, all rest are batch partitions. Are you saying that instead of placing CICS/TS above all the batch I should put them in a balanced group and give them a large share value? Thanks, Mike -----Original Message----- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Tom Duerbusch Sent: April 23, 2008 2:50 PM To: IBMVM@LISTSERV.UARK.EDU Subject: (LCOS: 10.6908) Re: Using SET SHARE, performance problem It's not 10% times 5 machines = 50%....NO It is an increase in 10% utilization for the amount of CPU that image was using. Say, you were at 75% cpu utilization prior to z/VSE 4.1. 10% is 7.5% added to 75% is 82.5% expected afterwards. That is for the sum of all the VSE machines. It is not 7.5% times 5 = 37.5% added to 75% = 112.5% If your CPU utilization, when batch isn't running, that is only CICS, database and communication, is under 85%, you don't have a cpu problem. Any problems is either I/O, paging, or scheduling. If you online load (again, no batch), was 85% or more, then, yes, the VSE upgrade did swamp you. If a CPU upgrade isn't in the near future, then you need to tune better (rob Peter to pay Paul). As you said, (I think), that it was the CICS/TS production partition was being impacted with batch was running in the same image, think again, it is the PRTY SHARE you are currently using. It was reset to IBM defaults and you need to update it to what you had it set to prior to the upgrade. Here, our base CPU utilization is about 25% without batch. We have 14 VSE systems running. When we run a lot of batch, with some extensive DB2, we run at 100% for hours. CICS response time, isn't affected. Tom Duerbusch THD Consulting Law of Cat Acceleration A cat will accelerate at a constant rate, until he gets good and ready to stop. >>> "Horlick, Michael" <[EMAIL PROTECTED]> 4/23/2008 1:29 PM >>> Unfortunately the guy with the EXPLORE/VM stats is off today. I have added them all up and the total VSEs add up to 90%. That's the minimum. There not capped. I have CICS/TS highest priority in all my VSEs. All the batch partitions are lowest in priority. We are going to have do some comparisons with EXPLORE data before and after the change. 10%. Times 5 machines. I guess I was a real dummy in not preparing the client for this increase in CPU usage. Mike -----Original Message----- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] On Behalf Of Tom Duerbusch Sent: April 23, 2008 2:14 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Using SET SHARE, performance problem Prior to the VSE upgrade, what was your CPU utilization? The IBM Performance documentation on VSE, shows about 10% increase in CPU when going from VSE/ESA 2.6 to z/VSE 4.1 (assuming everything else being the same). I find that SET SHARE ABSOLUTE to be fine. In you case, there are some batch jobs running in a VSE image. That image, as it is not being capped, can take 100% of the CPU, IF, it is available. But with the other VSE images also having ABSOLUTE available, assuming that the "adjusted" share is sufficient for CICS operations, they should be fine. "adjusted" share? Take all your "set share absolute" numbers and add them. If the total exceeds 100, then CP will "adjust" your shares down, all by the same percentage, so the total equals 100. When you calculate that number, you should adjust your "set share absolutes" to those numbers as that is the actual CPU % you are setting. Now that you have that number, you have to ask, is that "share" sufficient for CICS operation on my production systems? If not, those shares have to be adjusted upwards (and taking other shares down). If you don't do that, then a batch job, running on one VSE will cause production CICS performance problems. If the problem is the CICS in the VSE that is running the batch jobs, then you need to look at your PRTY SHARE settings within VSE. If VM is ending up giving you xx% of the CPU, and when you "adjust" your shares, you may find that VSE is giving CICS only 50% of the processor. Which is 1/2 of what VM is giving you. As you slice the slices, some slices (especially for CICS) can become too thin. Tom Duerbusch THD Consulting Cross-posted to both VMESA-L and VSE-L mailing lists Greetings, We have just converted the last of our 5 VSE machines to z/VSE 4.1.0 (from VSE/ESA 2.6.1) and are experiencing performance issues. My peak times are 98-100% utilization and people are complaining about poor response times. I don't know whether it's because I am using CICS data tables more now or because of the additional CPU utilization for z/VSE. Anyways, one question I have is the usage of the SET SHARE. I have been using the 'SHARE ABSOLUTE' directory control statement for each of my VSE machines (giving say 38% to one machine, giving 29% to another,etc...) with maximum share nolimit. The problems seem to occur when batch jobs are run in these predominately CICS/TS systems. I was wondering if maybe a SET SHARE RELATIVE technique would be more effective and what you do in prioritizing virtual machines within the physical machine? Thanks, Mike __________________________________________________________ This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message. To reply to our email administrator directly, send an email to [EMAIL PROTECTED] Law of Cat Acceleration A cat will accelerate at a constant rate, until he gets good and ready to stop.