Re: Third level VSE
On Fri, May 1, 2009 at 9:25 PM, Tom Duerbusch duerbus...@stlouiscity.com wrote: Take a look at Overhead Deltas for VSE Releases which is page 5 of the following PDF: You're probably a bit confused about the overhead that OP was talking about. The overhead deltas is the internal (additional) VSE processing on b -- Rob van der Heij Velocity Software http://www.velocitysoftware.com/
Re: Third level VSE
On Mon, May 4, 2009 at 9:43 AM, Rob van der Heij rvdh...@gmail.com wrote: On Fri, May 1, 2009 at 9:25 PM, Tom Duerbusch duerbus...@stlouiscity.com wrote: Take a look at Overhead Deltas for VSE Releases which is page 5 of the following PDF: You're probably a bit confused about the overhead that OP was talking about. The overhead deltas is the internal (additional) VSE processing on behalf of the workload running there. That is normal emulation time for CP. The CP overhead is something that VSE does not see. Just a matter of perspective. One man's productive work is another man's overhead. -- Rob van der Heij Velocity Software http://www.velocitysoftware.com/
Re: Third level VSE
He did initially point everyone to the VM overhead in a VM/VM/VSE system, but I also wonder about other items. They got a bigger processor, but is it the same number of engines? A uni to a larger dual processor (he talked about number of engines on the z890), is a lot of heart burn. VSE/ESA 2.3 doesn't have the Turbo dispatcher on by default. So, only one engine is used. But when you turn on Turbo dispatcher, then you also have additional overhead (per the foils). I do wonder if the second level VM and the third level VSE have all processors available to then (with turbo dispatch on)? When they have performance problems and you don't have a good performance monitor, my stance is, if IND doesn't show 95% or more CPU utilization, you don't have a CPU problem. A bad T/V ratio, is all about the CPU. Of course, unless real performance numbers are posted, this discussion is just bar talk G. Tom Duerbusch THD Consulting Rob van der Heij rvdh...@gmail.com 5/4/2009 2:43 AM On Fri, May 1, 2009 at 9:25 PM, Tom Duerbusch duerbus...@stlouiscity.com wrote: Take a look at Overhead Deltas for VSE Releases which is page 5 of the following PDF: You're probably a bit confused about the overhead that OP was talking about. The overhead deltas is the internal (additional) VSE processing on b -- Rob van der Heij Velocity Software http://www.velocitysoftware.com/
Re: Third level VSE
Thanks for the update. I can continue thinking about my own z/VM 5.2 to z/VM 5.4 upgrade plans. There are a lot of considerations. Near 24X7 shop or more near 9X5 (impacting test time). System programmer experience, not only in general, but in that particular shop. It is very easy to move a VSE image from 3rd level to second level. Any qualified VM systems programmer can do that in under an hour. And then you test and see if you find things that you didn't know about G. But I would spend time trying to get a 3rd level VSE to perform good. Spend the time in moving it to second level. BTW, if, on your first level VM system, IND doesn't show near 100%, then you don't have a CPU problem. You have CPU available for making up the lost of the assists, there is something else keeping you from using the rest of the CPU. I seem to recall that you said that you now have multiple processors. Is that true and did the old box have the same number of processors? Sometimes people compare total MIPs to total MIPs and are in for a shock when you can't use all the processors. VSE/ESA 2.3 doesn't have Turbo Dispatcher turned on as the default. Hence it will can only use 1 processor. Turning on TD costs you an additional 5% overhead (per the VSE release performance papers). But then you can use multiple processors, if you gave multiple processors to your second level VM system. It would be nice to have test time to test things and back out if necessary. But not all shops believe in test time and test systems the same way. Tom Duerbusch THD Consulting Berry van Sleeuwen berry.vansleeu...@xs4all.nl 4/29/2009 6:48 PM Ed (and Tom), Well, to be honest, about a year ago I already suggested to try to migrate into an zVM 5.x. And just before we moved the VM 2.2 I did repeat that suggestion. But according to some it would be too much of a risk. I guess it's a political risk, not a technical risk. And besides that, we were given too little time to plan a test on zVM before the move. But that's just my opinion. If it was up to me we would be on 5.4 next week. Anyway, as far as I can see it (I don have access to the detailed internals of the VM system) the only two risks would be ACF2 and VTUBES. And there is some external package I can't determine what risk it would have on zVM 5.4, I don't know if it is just CMS or that it does have some interaction that would require some VM/ESA level instead of zVM. ACF2 would require a new release and I don't know for sure what it would mean for VM 5.4 and VSE 2.3, if anything. But in all cases, we could just move the USER DIRECT into our host zVM 5.4 and try it. Perhaps we will try this in the next month but then we do need approval of those who are responsible for the service. Bottom line, the move of the system supposed to be as-is to minimize risks. For several reasons we now do not meet the requirements of the customer. Some were more or less expected but some realy do not meet our and their expectations. Regards, Berry. Edward M Martin schreef: Hello Barry, I have been watching this thread. I agree with Tom. Why not have VSE 2.3 run under z/VM 5.4 and have VM/ESA 2.2 run under z/VM 5.4 if need be? Ed Martin Aultman Health Foundation 330-363-5050 ext 35050 -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Tom Duerbusch Sent: Wednesday, April 29, 2009 11:42 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Third level VSE And what are the inhibitors that prevent you from running VSE 2.3 directly under z/VM 5.4? I have VSE 2.3.2 running on z/VM 5.2 on a z/890. I've been toying with the idea of upgrading VM this summer. Are there other products that are running under VM/ESA 2.2 that need to be on the same VM system as the VSE system? Tom Duerbusch THD Consulting
Re: Third level VSE
Gentlemen, Our experience is from VSE/ESA 2.3 + VM/ESA 3.1 to z/VM 5.2 and then to 5 .3. We run in a 9672, z890 and now in a z9. It is easy to upgrade VM releases, but we spent three years migrating fro m ACF/2 to Top Secret as directed ( forced ) by CA. This was the real probl em but I discarded the idea to work in a second level VM the third level VSE . At the same time we migrated from ACF/2 to Top Secret in the VSE/ESA and were ready to go for z/VSE. We have half of the VSE´s in z/VSE 3.1 and stopped because the CPU incr ease from VSE 2.3 to zVSE 3.1 was between 15 and 20 percent. And no CICS was migrated to Transaction Server. The issue is that VSE/ESA, VM/ESA and ACF/2 have no support but there are some costs to pay, working and CPU overhead. Regards. Marcelo.
Re: Third level VSE
Take a look at Overhead Deltas for VSE Releases which is page 5 of the following PDF: ftp://ftp.software.ibm.com/eserver/zseries/zos/vse/pdf3/techconf2007/sanantonio/E54_zVSE_Performance_Update.pdf Does your situation nearly match those numbers? Or are they quite a bit more? If quite a bit more, then I wonder what is causing it. If they nearly match, then you need some planning in order to do the proper migration. As the foil says, there is more overhead as you migrate to newer releases and functions. Apples to apples, it's just more overhead. But it enables you to start using new functions and facilities. That can lessen some of the overhead and/or provide better service to your users. Tom Duerbusch THD Consulting =?iso-8859-1?Q?Marcelo_Fazzito?= mfazz...@bancocredicoop.coop 5/1/2009 1:26 PM Gentlemen, Our experience is from VSE/ESA 2.3 + VM/ESA 3.1 to z/VM 5.2 and then to 5.3. We run in a 9672, z890 and now in a z9. It is easy to upgrade VM releases, but we spent three years migrating from ACF/2 to Top Secret as directed ( forced ) by CA. This was the real problem but I discarded the idea to work in a second level VM the third level VSE. At the same time we migrated from ACF/2 to Top Secret in the VSE/ESA and were ready to go for z/VSE. We have half of the VSÉs in z/VSE 3.1 and stopped because the CPU increase from VSE 2.3 to zVSE 3.1 was between 15 and 20 percent. And no CICS was migrated to Transaction Server. The issue is that VSE/ESA, VM/ESA and ACF/2 have no support but there are some costs to pay, working and CPU overhead. Regards. Marcelo.
Third level VSE
Hello listers, Before I begin, yes I know third level will cost us. Since SIE doesn't ge t down to the VSE we do not benefit from that and all CPU has to be emulate d. We have moved an old VM/ESA 2.2 with VSE 2.3 to a new z890 machine. Obviously this level of VM can't run on zseries so we have put the VM int o an zVM 5.4 LPAR. It does run and since they came from an old (ESCON) mach ine the batch (mostly IO) runs very good. We did expect to see some performance penalties and we already sized the machine to twice the MIPS they used to have. And for the most part the gu est VM has a TV ratio between 1.9 and 2.5. Usually during batch the TV is jus t above 2 but during online hours we also see a TV above 3. There are a few transactions that have a very bad performance. (from 2 seconds to 2.5 minutes) The time also depends on the other load in the VSE (or perhaps e ven in the CICS). We have been playing with lots of settings. Such as, two virtual CPU's in the guest, two virtual CPU's in VSE with TurboDispatcher, one dedicated C PU to the guest VM. Any ideas on how to speed up the guests? Other than migrating the guest V M to the zVM 5.4 host? TIA, Berry.
Re: Third level VSE
Avoid privileged instructions, such as IO and paging. Here VM's Minidisk cache can help to avoid I/O. You'd cache at the highest level, that is use VSE caching as much as possible, then VM/ESA's; you'd turn off MDC in z/VM, it is of no use to have two MDC levels. Have you looked at a performance monitor? Is the CPU full indeed?. Multiple processor configs would cause higher overheads too I guess and VSE's turbodispatcher is(was?) known not to be very performant, but if the VSE load requires more than one CP, you have no choice. I guess you know it is useless to define more virtual CP's than you have real ones available. 2009/4/29 Berry van Sleeuwen berry.vansleeu...@xs4all.nl Hello listers, Before I begin, yes I know third level will cost us. Since SIE doesn't get down to the VSE we do not benefit from that and all CPU has to be emulated. We have moved an old VM/ESA 2.2 with VSE 2.3 to a new z890 machine. Obviously this level of VM can't run on zseries so we have put the VM into an zVM 5.4 LPAR. It does run and since they came from an old (ESCON) machine the batch (mostly IO) runs very good. We did expect to see some performance penalties and we already sized the machine to twice the MIPS they used to have. And for the most part the guest VM has a TV ratio between 1.9 and 2.5. Usually during batch the TV is just above 2 but during online hours we also see a TV above 3. There are a few transactions that have a very bad performance. (from 2 seconds to 2.5 minutes) The time also depends on the other load in the VSE (or perhaps even in the CICS). We have been playing with lots of settings. Such as, two virtual CPU's in the guest, two virtual CPU's in VSE with TurboDispatcher, one dedicated CPU to the guest VM. Any ideas on how to speed up the guests? Other than migrating the guest VM to the zVM 5.4 host? TIA, Berry. -- Kris Buelens, IBM Belgium, VM customer support
Re: Third level VSE
Hello Kris, The guest runs with attached DASD so MDC is not applicable in this case. It doesn't look like IO is the problem here. But obviously any command processed in the guest will cause double the load in the host VM. So I do agree to avoid as much as possible. I don't know if MDC in the guest is possible or acceptable. Paging is not an issue. The host has 1G, the guest has 512M. The VSE runs NOPDS and the guest VM doesn't page. Yes, we run PTK. Running in the current config the guest VM can run up to 100%, and it does. When we assign 2 virtual CPU's to both VM and VSE (and start TD) we have seen the guest running up to about 190%. Also VSE does show processing at 100% CPU. But even an increase to 2 CPU's doesn't lowe r the transaction times for the transactions in question to an acceptable l evel. Regards, Berry.
AW: Third level VSE
AFAIK, in the third level there is no SIE possible. That makes for a great performance impediment. Kind regards, Willy -Ursprüngliche Nachricht- Von: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] Im Auftrag von Berry van Sleeuwen Gesendet: Mittwoch, 29. April 2009 12:01 An: IBMVM@LISTSERV.UARK.EDU Betreff: Re: Third level VSE Hello Kris, The guest runs with attached DASD so MDC is not applicable in this case. It doesn't look like IO is the problem here. But obviously any command processed in the guest will cause double the load in the host VM. So I do agree to avoid as much as possible. I don't know if MDC in the guest is possible or acceptable. Paging is not an issue. The host has 1G, the guest has 512M. The VSE runs NOPDS and the guest VM doesn't page. Yes, we run PTK. Running in the current config the guest VM can run up to 100%, and it does. When we assign 2 virtual CPU's to both VM and VSE (and start TD) we have seen the guest running up to about 190%. Also VSE does show processing at 100% CPU. But even an increase to 2 CPU's doesn't lower the transaction times for the transactions in question to an acceptable level. Regards, Berry.
Re: Third level VSE
Berry, The guest runs with attached DASD so MDC is not applicable in this case. Do you mean: attached to the VSE-guest or to the VM/ESA-guest? If attached to the VSE-guest: is there still a real performance benefit in attaching dasd to a 3rd level VSE-guest? Anyway, MDC has the potential of giving your VSE-throughput a real boost (it did in our case), so in order for the VSE-guest to benefit from MDC in the VM/ESA system, I would: - in the first level z/VM: attach the dasd to the 2nd level VM/ESA guest. - in the 2nd level VM/ESA: attach the dasd to SYSTEM, and define fullpack MDISKs for the 3rd level VSE guest. Also, if enough storage is available in VSE, add more buffers to your CICS LSR-pools and/or database system. Bye, Geert. -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Berry van Sleeuwen Sent: woensdag 29 april 2009 12:01 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Third level VSE Hello Kris, The guest runs with attached DASD so MDC is not applicable in this case. It doesn't look like IO is the problem here. But obviously any command processed in the guest will cause double the load in the host VM. So I do= agree to avoid as much as possible. I don't know if MDC in the guest is possible or acceptable. Paging is not an issue. The host has 1G, the guest has 512M. The VSE runs= NOPDS and the guest VM doesn't page. Yes, we run PTK. Running in the current config the guest VM can run up to= 100%, and it does. When we assign 2 virtual CPU's to both VM and VSE (and= start TD) we have seen the guest running up to about 190%. Also VSE does show processing at 100% CPU. But even an increase to 2 CPU's doesn't lowe= r the transaction times for the transactions in question to an acceptable l= evel. Regards, Berry. DISCLAIMER This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify postmas...@vanbreda.be This footnote also confirms that this email has been checked for the presence of viruses. Informatica J.Van Breda Co NV BTW BE 0427 908 174
Re: Third level VSE
Geert, Do you mean: attached to the VSE-guest or to the VM/ESA-guest? If attached to the VSE-guest: is there still a real performance benefit in attaching dasd to a 3rd level VSE-guest? Attached to the guest VM. I don't know if there would be any advantage in attaching to third level, other than an as-is move to a new location. Anyway, MDC has the potential of giving your VSE-throughput a real boost (it did in our case), so in order for the VSE-guest to benefit from MDC in the VM/ESA system, I would: - in the first level z/VM: attach the dasd to the 2nd level VM/ESA guest. - in the 2nd level VM/ESA: attach the dasd to SYSTEM, and define fullpack MDISKs for the 3rd level VSE guest. But would that also boost non-IO load? I expect the problem is CPU load i n some stupid program. In that case any MDC wouldn't help me for that. The only advantage would be an improvement of the batch processing. Also, if enough storage is available in VSE, add more buffers to your CICS LSR-pools and/or database system. Storage enough. We have 512M spare in the host VM that isn't used. And th e VSE runs NOPDS so we can increase it just by adding virtual storage in th e VSE guest directory. If VM runs out of storage (or starts paging at any serious level) we can add virual storage to the guest VM. Regards, Berry.
Re: Third level VSE
Only a subset of privileged instructions require intervention from VM hence huge overhead for 3'th level VSE. MOVE kind instructions for example would ran at native speed, no matter how deed the SIE instruction is nested. Driving IO is the most obvious area that require VM intervention. Avoiding IO will save CPU cycles that then can be used for something else. So as Geert and I suggest: buffer as much as possible in VSE. the IOs VSE will still issue will be seen by the second level VM, if it can find the data in the MDC, it will not launch an IO that the first level VM will need to handle. Give MDC a try by using MDISKs for VSE, but turn MDC off in the first level VM, and give the secondlevel VM as much storage as you can. MDC will transform IO requests into fulltrack IOs, so with one IO you get much more than requested; sequential processing will fly. Random access: may vary, if the MDC is large enough you may still benefit. 2009/4/29 Berry van Sleeuwen berry.vansleeu...@xs4all.nl: Geert, Do you mean: attached to the VSE-guest or to the VM/ESA-guest? If attached to the VSE-guest: is there still a real performance benefit in attaching dasd to a 3rd level VSE-guest? Attached to the guest VM. I don't know if there would be any advantage in attaching to third level, other than an as-is move to a new location. Anyway, MDC has the potential of giving your VSE-throughput a real boost (it did in our case), so in order for the VSE-guest to benefit from MDC in the VM/ESA system, I would: - in the first level z/VM: attach the dasd to the 2nd level VM/ESA guest. - in the 2nd level VM/ESA: attach the dasd to SYSTEM, and define fullpack MDISKs for the 3rd level VSE guest. But would that also boost non-IO load? I expect the problem is CPU load in some stupid program. In that case any MDC wouldn't help me for that. The only advantage would be an improvement of the batch processing. Also, if enough storage is available in VSE, add more buffers to your CICS LSR-pools and/or database system. Storage enough. We have 512M spare in the host VM that isn't used. And the VSE runs NOPDS so we can increase it just by adding virtual storage in the VSE guest directory. If VM runs out of storage (or starts paging at any serious level) we can add virual storage to the guest VM. Regards, Berry. -- Kris Buelens, IBM Belgium, VM customer support
Re: Third level VSE
Well, if the problem is caused by a CPU-intensive CICS-program, then I would expect that you would have seen that problem on your old system as well (when we put a really CPU-intensive CICS-program into production, we get calls from frustrated users immediately). But you'll need a CICS monitor to look into the resource usage of your CICS-transactions... A couple of other things to consider regarding CPU-resources: - is the VM/ESA guest the only (heavy) guest in the z/VM system or is competing with others? - was CP SET SHARE set appropriately for this guest in the z/VM system? - did you provide QUICKDSP for the VM/ESA guest in the z/VM system? - does the LPAR get all the resources you think its getting (check the Change Logical Partition Controls task or the activity display on the HMC)? Bye, Geert. -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Berry van Sleeuwen Sent: woensdag 29 april 2009 13:51 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Third level VSE Geert, Do you mean: attached to the VSE-guest or to the VM/ESA-guest? If attached to the VSE-guest: is there still a real performance benefit in attaching dasd to a 3rd level VSE-guest? Attached to the guest VM. I don't know if there would be any advantage in= attaching to third level, other than an as-is move to a new location. Anyway, MDC has the potential of giving your VSE-throughput a real boost= (it did in our case), so in order for the VSE-guest to benefit from MDC in the VM/ESA system, I would: - in the first level z/VM: attach the dasd to the 2nd level VM/ESA guest. - in the 2nd level VM/ESA: attach the dasd to SYSTEM, and define fullpack MDISKs for the 3rd level VSE guest. But would that also boost non-IO load? I expect the problem is CPU load i= n some stupid program. In that case any MDC wouldn't help me for that. The only advantage would be an improvement of the batch processing. Also, if enough storage is available in VSE, add more buffers to your CICS LSR-pools and/or database system. Storage enough. We have 512M spare in the host VM that isn't used. And th= e VSE runs NOPDS so we can increase it just by adding virtual storage in th= e VSE guest directory. If VM runs out of storage (or starts paging at any serious level) we can add virual storage to the guest VM. Regards, Berry. DISCLAIMER This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify postmas...@vanbreda.be This footnote also confirms that this email has been checked for the presence of viruses. Informatica J.Van Breda Co NV BTW BE 0427 908 174
Re: Third level VSE
Berry van Sleeuwen wrote: But would that also boost non-IO load? I expect the problem is CPU load in some stupid program. In that case any MDC wouldn't help me for that. The only advantage would be an improvement of the batch processing. Then engage a performance monitor under VSE, or the System Activity Display to determine where the CPU Cycles are going. But, the best I/O is no I/O, I'm with Kris and Geert, try to reduce the number of I/O's as much as possible. -- Rich Smrcina Phone: 414-491-6001 http://www.linkedin.com/in/richsmrcina Catch the WAVV! http://www.wavv.org WAVV 2009 - Orlando, FL - May 15-19, 2009
Re: Third level VSE
On Wednesday, 04/29/2009 at 08:17 EDT, Kris Buelens kris.buel...@gmail.com wrote: Only a subset of privileged instructions require intervention from VM hence huge overhead for 3'th level VSE. MOVE kind instructions for example would ran at native speed, no matter how deed the SIE instruction is nested. An unassisted SIE instruction is trapped by the underlying z/VM system and trimmed to reflect what the underlying z/VM system knows about the guest who issued the SIE. Then that underlying z/VM issues a SIE. With few exceptions, all nth-level guests run under real SIE. Of course, you haven't got much of a time slice and there are fewer guest pages resident in SIE-accessible memory, so you don't stay in SIE very long. Hence the poor performance. But while that guest is in SIE, he's running at full speed. There are some kinds of pre/post-real SIE conditions that have to be simulated by each underlying z/VM, so sometimes you never reach real SIE. Alan Altmark z/VM Development IBM Endicott
Re: Third level VSE
It looks like we were a bit fooled by the customer. After a lot of discussion it looks like it is not only CPU constrained. And also, at least in part, they already had problems in the old machine (and they forgot to mention that little detail). It used to be just acceptable but with the current overhead the performance dropped too much. As for your questions, the LPAR is the only one in use on the hardware. The VM guest is the only machine running any actual load. Others are DIRMAINT and a CMS servicemachine, things like that. The VSE in the guest VM is the top user. We did find that when the guest had been given two CPU's. Most of the time the LPAR ran at just over 100%. Sometimes it spiked to 120%. Once the VSE got it's second CPU and TD the load went up to close to 200%. So we can conclude the VSE is the top user here. Tomorrow we move the guest into an LPAR on a z9. Perhaps that would give us a faster CP. We have to look into the caching, like you and Kris suggested. Perhaps that could also give us some additional speed. And we also look into other configurations that would normally not do that much but it could be just enough to get an acceptable performance. Thanks, Berry. Dieltiens Geert schreef: Well, if the problem is caused by a CPU-intensive CICS-program, then I would expect that you would have seen that problem on your old system as well (when we put a really CPU-intensive CICS-program into production, we get calls from frustrated users immediately). But you'll need a CICS monitor to look into the resource usage of your CICS-transactions... A couple of other things to consider regarding CPU-resources: - is the VM/ESA guest the only (heavy) guest in the z/VM system or is competing with others? - was CP SET SHARE set appropriately for this guest in the z/VM system? - did you provide QUICKDSP for the VM/ESA guest in the z/VM system? - does the LPAR get all the resources you think its getting (check the Change Logical Partition Controls task or the activity display on the HMC)? Bye, Geert. -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Berry van Sleeuwen Sent: woensdag 29 april 2009 13:51 To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Third level VSE Geert, Do you mean: attached to the VSE-guest or to the VM/ESA-guest? If attached to the VSE-guest: is there still a real performance benefit in attaching dasd to a 3rd level VSE-guest? Attached to the guest VM. I don't know if there would be any advantage in= attaching to third level, other than an as-is move to a new location. Anyway, MDC has the potential of giving your VSE-throughput a real boost= (it did in our case), so in order for the VSE-guest to benefit from MDC in the VM/ESA system, I would: - in the first level z/VM: attach the dasd to the 2nd level VM/ESA guest. - in the 2nd level VM/ESA: attach the dasd to SYSTEM, and define fullpack MDISKs for the 3rd level VSE guest. But would that also boost non-IO load? I expect the problem is CPU load i= n some stupid program. In that case any MDC wouldn't help me for that. The only advantage would be an improvement of the batch processing. Also, if enough storage is available in VSE, add more buffers to your CICS LSR-pools and/or database system. Storage enough. We have 512M spare in the host VM that isn't used. And th= e VSE runs NOPDS so we can increase it just by adding virtual storage in th= e VSE guest directory. If VM runs out of storage (or starts paging at any serious level) we can add virual storage to the guest VM. Regards, Berry. DISCLAIMER This email and any files transmitted with it are confidential and intended solely for the use of the individual or entity to whom they are addressed. If you have received this email in error please notify postmas...@vanbreda.be This footnote also confirms that this email has been checked for the presence of viruses. Informatica J.Van Breda Co NV BTW BE 0427 908 174
Re: Third level VSE
On Wed, Apr 29, 2009 at 2:49 PM, Alan Altmark alan_altm...@us.ibm.com wrote: An unassisted SIE instruction is trapped by the underlying z/VM system and trimmed to reflect what the underlying z/VM system knows about the guest who issued the SIE. Then that underlying z/VM issues a SIE. With few exceptions, all nth-level guests run under real SIE. Of course, you haven't got much of a time slice and there are fewer guest pages resident in SIE-accessible memory, so you don't stay in SIE very long. Hence the poor performance. But while that guest is in SIE, he's running at full speed. There are some kinds of pre/post-real SIE conditions that have to be simulated by each underlying z/VM, so sometimes you never reach real SIE. You need to know where to look to see spot the recognize the overhead. I'm not sure you're saying the same, but my experience is that the overhead is not because of the SIE instruction. Surely CP needs to massage the SIEBKs to get things right, but that's not the big cost. It's because of the reduced function of some things under V/SIE. With Linux running 3rd level for example, it appears the big hit is the way copy-on-write works in that you get a lot of program checks. As long as you don't go beyond the hardware support, the program check can be reflected to the guest itself. But with more levels of DAT stacked, the result is that first level CP has to emulate DAT as if we had no hardware support and do the shadow table smoke and mirrors by hand. So you should see overhead on the 1st level CP. 2nd level CP is unaware of what is happening and will merely assume CPU contention. I'd expect Berry to be more lucky with VSE maybe less heave do deliberate program checks, especially when VSE itself does not page. As always, one would need to look at real data... Rob -- Rob van der Heij Velocity Software http://www.velocitysoftware.com/
Re: Third level VSE
And what are the inhibitors that prevent you from running VSE 2.3 directly under z/VM 5.4? I have VSE 2.3.2 running on z/VM 5.2 on a z/890. I've been toying with the idea of upgrading VM this summer. Are there other products that are running under VM/ESA 2.2 that need to be on the same VM system as the VSE system? Tom Duerbusch THD Consulting Berry van Sleeuwen berry.vansleeu...@xs4all.nl 4/29/2009 1:52 AM Hello listers, Before I begin, yes I know third level will cost us. Since SIE doesn't get down to the VSE we do not benefit from that and all CPU has to be emulated. We have moved an old VM/ESA 2.2 with VSE 2.3 to a new z890 machine. Obviously this level of VM can't run on zseries so we have put the VM into an zVM 5.4 LPAR. It does run and since they came from an old (ESCON) machine the batch (mostly IO) runs very good. We did expect to see some performance penalties and we already sized the machine to twice the MIPS they used to have. And for the most part the guest VM has a TV ratio between 1.9 and 2.5. Usually during batch the TV is just above 2 but during online hours we also see a TV above 3. There are a few transactions that have a very bad performance. (from 2 seconds to 2.5 minutes) The time also depends on the other load in the VSE (or perhaps even in the CICS). We have been playing with lots of settings. Such as, two virtual CPU's in the guest, two virtual CPU's in VSE with TurboDispatcher, one dedicated CPU to the guest VM. Any ideas on how to speed up the guests? Other than migrating the guest VM to the zVM 5.4 host? TIA, Berry.
Re: Third level VSE
Hello Barry, I have been watching this thread. I agree with Tom. Why not have VSE 2.3 run under z/VM 5.4 and have VM/ESA 2.2 run under z/VM 5.4 if need be? Ed Martin Aultman Health Foundation 330-363-5050 ext 35050 -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Tom Duerbusch Sent: Wednesday, April 29, 2009 11:42 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Third level VSE And what are the inhibitors that prevent you from running VSE 2.3 directly under z/VM 5.4? I have VSE 2.3.2 running on z/VM 5.2 on a z/890. I've been toying with the idea of upgrading VM this summer. Are there other products that are running under VM/ESA 2.2 that need to be on the same VM system as the VSE system? Tom Duerbusch THD Consulting
Re: Third level VSE
Ed (and Tom), Well, to be honest, about a year ago I already suggested to try to migrate into an zVM 5.x. And just before we moved the VM 2.2 I did repeat that suggestion. But according to some it would be too much of a risk. I guess it's a political risk, not a technical risk. And besides that, we were given too little time to plan a test on zVM before the move. But that's just my opinion. If it was up to me we would be on 5.4 next week. Anyway, as far as I can see it (I don have access to the detailed internals of the VM system) the only two risks would be ACF2 and VTUBES. And there is some external package I can't determine what risk it would have on zVM 5.4, I don't know if it is just CMS or that it does have some interaction that would require some VM/ESA level instead of zVM. ACF2 would require a new release and I don't know for sure what it would mean for VM 5.4 and VSE 2.3, if anything. But in all cases, we could just move the USER DIRECT into our host zVM 5.4 and try it. Perhaps we will try this in the next month but then we do need approval of those who are responsible for the service. Bottom line, the move of the system supposed to be as-is to minimize risks. For several reasons we now do not meet the requirements of the customer. Some were more or less expected but some realy do not meet our and their expectations. Regards, Berry. Edward M Martin schreef: Hello Barry, I have been watching this thread. I agree with Tom. Why not have VSE 2.3 run under z/VM 5.4 and have VM/ESA 2.2 run under z/VM 5.4 if need be? Ed Martin Aultman Health Foundation 330-363-5050 ext 35050 -Original Message- From: The IBM z/VM Operating System [mailto:ib...@listserv.uark.edu] On Behalf Of Tom Duerbusch Sent: Wednesday, April 29, 2009 11:42 AM To: IBMVM@LISTSERV.UARK.EDU Subject: Re: Third level VSE And what are the inhibitors that prevent you from running VSE 2.3 directly under z/VM 5.4? I have VSE 2.3.2 running on z/VM 5.2 on a z/890. I've been toying with the idea of upgrading VM this summer. Are there other products that are running under VM/ESA 2.2 that need to be on the same VM system as the VSE system? Tom Duerbusch THD Consulting
