Thanks for the update. It's the 3rd level dispatches killing your response time. Even if response time were to be slower due to hardware differences, your amount of slowdown is too drastic. Try recovering to an LPAR. David James Melin wrote:
I am going to address everyone's responses (thank you all) in this e-mail rather than reply multiple times: David Kreuter wrote: I would first look at any waiting, queueing, etc from the 1st and 2nd level system. I am willing to speculate without seeing data that your world of hurt is due the configuration of zvm under zvm. For a linux machine to get a dispatch it is going through two levels of CP. Years ago this caused extreme pain. David ------------------------------------ That was the first thing we looked at using the recovery system's perfkit (which I'm told the vendor allowed us to use on a ONE time basis - we wont have this) and our own perfkit. We saw lots of SIE, but no queueing or waiting. The Top level VM had the CP's dedicated so from it's perspective they were always 100% busy cuz it was 'spinnig' waiting for work. We also saw that there was lots of activity in moving things below the 2 GB line and back. But was that abnormal? Can't say. ------------------------------------- Alan Altmark wrote: I would suggest devising a scenario wherein the guests of the failed z/VM system are recovered as first-level guests on the recovery system. Once the DR vendor turns the crank on the hardware to a later generation box, basic mode is gone and the SIE hardware assist for the (now) 3rd level guests is not available. ------------------------------------ I had this discussion yesterday. Our head systems programmer wants to pursue the problem from the configuration that we have in place (broken) and let support services determine why Java performance is slow in the Linux under z/VM under z/VM environment. I tried to make the case, using the State of Minnesota as an example - They don't run their recovered VM under the DR vendor VM. The people who make the ultimate decision on how we will recover don't seem to think that it matters how the State does it, or that nobody else seems to do it the way we do it either. I think they are of the opinion that to pursue multiple different scenarios will make things confusing. I think it would reveal things to look at REGARDLESS of what happens. Performance improves? It's a VM under VM thing. Performance does NOT improve, it's a base configuration problem on the recovery system that is the doing of the DR vendor. ------------------------------------ Marcy Cortes wrote: We recover the VM system to an LPAR, not under VM. Because VM senses all the i/o, the only changes we need to make for addressing differences is to DFSMS RMS & VMTAPE for tape drive numbers and to TCPIP for OSA differences (we have alternate tcpip profile which goes into effect based on node name change based on cpuid so that's pretty automatic). I take that back a little bit - we do recover VM system volumes under a VM starter system, then we IPL that restored system to an LPAR (not VM under VM). We do it inhouse though, so we aren't under any vendor constraints. Do you also run a z900 in production? Java perf is much better on z990's and even better on z9. ------------------------------------ Sadly, we're running on a z900. With the new z9 offerings, I suspect that we might be able to get one in here to replace the z900 but again that's out of my hands. If there would be no performance hit to our z/OS recovery, I'd LOVE to recover in LPAR mode - using the current VM setup in one LPAR. That way our z/OS recovery doesn't need to change (we've played into that environment quite nicely) but our VM can then come up in an LPAR with minimal tailoring. We could even do the tailoring on the guest we currently used to run it - shut it down and IPL it in the LPAR. Anyway, thanks for the feedback. It seems to support my position better than the other folks. -J ---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
---------------------------------------------------------------------- For LINUX-390 subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit http://www.marist.edu/htbin/wlvindex?LINUX-390
