Alan, Thanks for the Clarification.
Based on that I shouldn't be seeing the performance I am seeing.
I'm just trying to figure out what in hell can cause a performance difference
of 227:1 at DR vs back home. Yes. That's correct 227:1 sometimes
slightly better, sometimes slightly worse. JITC is reporting that it is enabled.
An application that loads the initial page here in 1 second took 3:47 to load
at DR.
If we're under basic mode, w/2 levels of VM, we should not be getting the SIE
in software penalty. I understand that VM under VM will be slightly
slower unless you do certain tuning steps. The behaviour is certainly more like
I would expect in software SIE rather than in VM under VM.
The consensus of the learned here is that the problem lies in Java.
I disagree. There is no logical reason to explain why Java at DR would be
performing so poorly - we make no configuration changes to Linux except DNS
- and even then the major IP stuff is handled in /etc/hosts and got adjusted to
point to the correct IP address (Both wire and Hipersocket) of the
recovery system on a flat network. Same subnet.
I believe that the poor Java performance is a manifestation of a different
problem, be it VM levels, be it maintenance, be it configuration of the
environment - something. I cannot prove that this is the case without running
the Linux guests 'first level'. I can't get any buy-in from the people
who have more say in this than I, to execute the Linux in a first level guest
so we can see how it compares to running our VM under the DR VM - The
fact not withstanding that nobody here on the list recovers that way. For
similar reasons.
If anyone has any insight into configuration issues that could cause this, I'd
love to hear it. I personally don't think taking Java core dumps with
kill -3 and kill -11 of high resource Java threads at the next DR test is going
to reveal the source of the problem. I strongly feel that the problem
lies in VM/VM interaction and since Linux on z/VM cannot see that layer of
interaction, all the Java core dumps are going to tell us is where it was
spending time inside Linux.
Alan Altmark <[EMAIL PROTECTED]>
Sent by: Linux on 390 Port
<[email protected]>
To
[email protected]
cc
05/04/2006 05:41 PM
Subject
Re: What
configurations are people using for Disaster Recovery for Linux under
Please respond to z/VM
Linux on 390 Port <[email protected]>
On Thursday, 05/04/2006 at 02:19 EST, James Melin
<[EMAIL PROTECTED]> wrote:
> I just want to reconcile what the People here are saying with what the
folk on
> the list say regarding what constitutes a 3rd level guest....
>
> I'm being told by our head sysprog AND someone else with considerably
more VM
> experience (he's the new guy) that in Basic mode, the DR VM system is
> first Level, our VM is second level and therefore any guests running
under OUR
> VM are second level.
>
> It sounds to me like people here on the are saying that the DR VM system
is
> first level, OUR VM system is second level, and the Linux Guests running
> under our VM under the DR vendor VM are in fact executing third level,
and
> hitting the SIE not in hardware problem.
>
> Which is correct?
LOL. It just depends on training and local custom. Some people use the
"level" to describe levels of virtualization. There is "1st-level SIE"
(SIE1) and "2nd-level SIE" (SIE2), so some say that any operating system
which runs under the ausipices of SIE2 is a "2nd-level guest". But I
would say the majority would use "3rd level" to describe the guests of a
2nd level z/VM system.
In Basic mode, 1st level CP (CP1) uses SIE1 to dispatch the the 2nd level
CP (CP2), which uses SIE2 to run your 3rd-level guest (Guest3). Everything
is wonderful.
In LPAR mode, LPAR uses SIE1 to dispatch CP1, which uses SIE2 to dispatch
CP2, leaving leaves none for Guest3. This means that when CP2 issues the
SIE instruction, it will cause a SIE2 break on CP1. That, in turn, causes
CP1 to construct a SIE descriptor, converting CP2's view of Guest3 to that
viewed by CP1, or to simulate whatever needs to be simulated. This
process is called "Virtual SIE" (VSIE).
The itty bitty time slices and possibly small amount of resident guest
memory in CP1 real memory means that VSIE doesn't perform very well.
Are we having fun yet?
Alan Altmark
z/VM Development
IBM Endicott
----------------------------------------------------------------------
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
