This is not your problem, but I was just courious, when you went to z/VSE 4.1 did you change the storage size for z/VSE machines? Did you go over 2G? NOPDS?? Just courious.
-----Original Message----- From: The IBM z/VM Operating System [mailto:[EMAIL PROTECTED] Behalf Of Horlick, Michael Sent: Wednesday, April 23, 2008 1:30 PM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Using SET SHARE, performance problem 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.
