Re: 64-Bit Storage / Performance Issues with z/OS 1.10

[Scott Rowe]

I think Bob Rogers would disagree with you on this, at least on a z10 with 
large frames.  Worst case seems to be same throughput as 31-bit, while best 
case is significantly better throughput.

>>> Kirk Wolf  03/19/10 4:41 PM >>>
RE: z/OS 64-bit Java -

My preference is to run the 31-bit JVM on z/OS unless you really need
64-bit (eg. you need more than 1.5G java heap).   Although SDK6-64 has
come a long way in eliminating the performance penalty, it is still
heavier than 31-bit.   Also, consider that many z/OS services are not
64-bit enabled yet, so with a 64-bit JVM you end up moving stuff below
the line when doing many OS service calls.   Of course, this is a
moving target; it could be that 64-bit Java is just as  fast for some
workloads if you tune it just right.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html



CONFIDENTIALITY/EMAIL NOTICE: The material in this transmission contains 
confidential and privileged information intended only for the addressee.  If 
you are not the intended recipient, please be advised that you have received 
this material in error and that any forwarding, copying, printing, 
distribution, use or disclosure of the material is strictly prohibited.  If you 
have received this material in error, please (i) do not read it, (ii) reply to 
the sender that you received the message in error, and (iii) erase or destroy 
the material. Emails are not secure and can be intercepted, amended, lost or 
destroyed, or contain viruses. You are deemed to have accepted these risks if 
you communicate with us by email. Thank you.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 64-Bit Storage / Performance Issues with z/OS 1.10

[Kirk Wolf]

RE: z/OS 64-bit Java -

My preference is to run the 31-bit JVM on z/OS unless you really need
64-bit (eg. you need more than 1.5G java heap).   Although SDK6-64 has
come a long way in eliminating the performance penalty, it is still
heavier than 31-bit.   Also, consider that many z/OS services are not
64-bit enabled yet, so with a 64-bit JVM you end up moving stuff below
the line when doing many OS service calls.   Of course, this is a
moving target; it could be that 64-bit Java is just as  fast for some
workloads if you tune it just right.

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 64-Bit Storage / Performance Issues with z/OS 1.10

[Mark Zelden]

On Thu, 18 Mar 2010 21:40:18 -0700, Norman Hollander on DesertWiz
 wrote:

>Unless you have DB2 v10 or Java 6 SP3, there is no value to specifying
>LFA.
>

LFAREA

I haven't checked, but according to a SHARE presentation from last summer
(Bob Rogers, Getting the most from a z10), it was Java 6 SR1:


Exploiters
• Java 6 SR1: requests large pages to back the Java Heap
• DB2 Version X: intends to exploit large pages for buffer pools


So DB2 Version X is V10 (gee, what a surprise).   I missed the beta
announcement for V10 last month. Was GA announced at SHARE this week?

Mark
--
Mark Zelden - Zelden Consulting Services - z/OS, OS/390 and MVS   
mailto:mzel...@flash.net  
Mark's MVS Utilities: http://home.flash.net/~mzelden/mvsutil.html 
Systems Programming expert at http://expertanswercenter.techtarget.com/

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 64-Bit Storage / Performance Issues with z/OS 1.10

[Shmuel Metz (Seymour J.)]

In <4b9f84cd.401d.003...@bcbsnc.com>, on 03/16/2010
   at 01:17 PM, Jack Oakley  said:

>Migrating from z/OS 1.9 to 1.10.  z/OS 1.10 exploits more 64-bit storage
>(GRS, SMSPDSE, TRACE, etc). 

Two key questions:

 1. To what extent is it actually requiring more storage, as opposed
 to simply changing where it requests the storage?

 2. To what extent is it increasing the working set, as opposed to
storage that is usually paged out? Put another way, does it
require more real storage, or only virtual?
 
-- 
 Shmuel (Seymour J.) Metz, SysProg and JOAT
 ISO position; see  
We don't care. We don't have to care, we're Congress.
(S877: The Shut up and Eat Your spam act of 2003)

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 64-Bit Storage / Performance Issues with z/OS 1.10

[Jack Oakley]

Thanks Norman, I was wondering at what point I should consider specifying the 
LFAREA value.
 
Here's an update to our 64-Bit storage / poor performance issue:
I didn't mention this before, but our periods of poor performance was due to 
SRM overhead as it searched for available above the bar frames and performed 
frame stealing in order to bring the 1MB (per logical CP) system trace buffers 
into core to process each abend.  One of IBM's recommendations was to either 
drop our central storage allocation from 4GB to 2GB or add more.  We felt that 
dropping back to 2GB would cause memory constraints below the bar, so last 
weekend I added 1GB to the test LPAR bringing the total central storage 
allocation to 5GB.  The abend scenario that would typically cause the slow down 
condition has been frequently tested since then and here we are at the end of 
the workweek and the slow down condition has not reoccurred.  So adding more 
memory has solved our problem just as described in II14465.  It depends on how 
much above the 2GB bar central storage you have allocated and what you have 
running that's exploiting that 64-bit storage as to whether you'll have this 
problem or not.  If you have configurations similar to ours, watch out for this 
one when you upgrade to z/OS 1.10/1.11.
Jack

>>> Norman Hollander on DesertWiz  3/19/2010 
>>> 12:40 AM >>>
Unless you have DB2 v10 or Java 6 SP3, there is no value to specifying
LFA.

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Jack Oakley
Sent: Wednesday, March 17, 2010 SYSN 03:52 AM
To: IBM-MAIN@bama.ua.edu 
Subject: Re: 64-Bit Storage / Performance Issues with z/OS 1.10

No LFAREA specified in IEASYSxx so taking the default (no real storage used
to back 1M pages).

>>> Gil Peleg  3/17/2010 5:44 AM >>>
Jack,
What value do you specify in IEASYSxx for LFAREA= ? The default is none,
which means no real storage should be used to back 1M pages. So if you are
taking the default, your problem is probably not caused by large pages.

HTH,
Gil.

On Tue, Mar 16, 2010 at 7:17 PM, Jack Oakley  wrote:

> Curious to learn if anyone else has experienced this problem and what you
> did to resolve it.
>
> Migrating from z/OS 1.9 to 1.10.  z/OS 1.10 exploits more 64-bit storage
> (GRS, SMSPDSE, TRACE, etc).  The system trace (TRACE) buffers not only
> increased from 256K to 1M per logical CP, but also moved above the 2GB
bar.
>  We are experiencing very poor performance mostly during abend processing
as
> described in II14465.
>
> Configuration:
> LPAR has 4GB real storage.
> 2 logical CPs
>
> In addition to z/OS, significant exploiters of 64-bit storage are:
> Four DB2 v8/v9 systems
> Three IMS v10 systems
> Four CICS Transaction Server v3.2 regions
> Two Java 1.6 (64-bit) application address spaces
>
> Regards,
> Jack Oakley
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html 
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html 

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 64-Bit Storage / Performance Issues with z/OS 1.10

[Norman Hollander on DesertWiz]

Unless you have DB2 v10 or Java 6 SP3, there is no value to specifying
LFA.

-Original Message-
From: IBM Mainframe Discussion List [mailto:ibm-m...@bama.ua.edu] On Behalf
Of Jack Oakley
Sent: Wednesday, March 17, 2010 SYSN 03:52 AM
To: IBM-MAIN@bama.ua.edu
Subject: Re: 64-Bit Storage / Performance Issues with z/OS 1.10

No LFAREA specified in IEASYSxx so taking the default (no real storage used
to back 1M pages).

>>> Gil Peleg  3/17/2010 5:44 AM >>>
Jack,
What value do you specify in IEASYSxx for LFAREA= ? The default is none,
which means no real storage should be used to back 1M pages. So if you are
taking the default, your problem is probably not caused by large pages.

HTH,
Gil.

On Tue, Mar 16, 2010 at 7:17 PM, Jack Oakley  wrote:

> Curious to learn if anyone else has experienced this problem and what you
> did to resolve it.
>
> Migrating from z/OS 1.9 to 1.10.  z/OS 1.10 exploits more 64-bit storage
> (GRS, SMSPDSE, TRACE, etc).  The system trace (TRACE) buffers not only
> increased from 256K to 1M per logical CP, but also moved above the 2GB
bar.
>  We are experiencing very poor performance mostly during abend processing
as
> described in II14465.
>
> Configuration:
> LPAR has 4GB real storage.
> 2 logical CPs
>
> In addition to z/OS, significant exploiters of 64-bit storage are:
> Four DB2 v8/v9 systems
> Three IMS v10 systems
> Four CICS Transaction Server v3.2 regions
> Two Java 1.6 (64-bit) application address spaces
>
> Regards,
> Jack Oakley
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html 
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 64-Bit Storage / Performance Issues with z/OS 1.10

[Jack Oakley]

No LFAREA specified in IEASYSxx so taking the default (no real storage used to 
back 1M pages).

>>> Gil Peleg  3/17/2010 5:44 AM >>>
Jack,
What value do you specify in IEASYSxx for LFAREA= ? The default is none,
which means no real storage should be used to back 1M pages. So if you are
taking the default, your problem is probably not caused by large pages.

HTH,
Gil.

On Tue, Mar 16, 2010 at 7:17 PM, Jack Oakley  wrote:

> Curious to learn if anyone else has experienced this problem and what you
> did to resolve it.
>
> Migrating from z/OS 1.9 to 1.10.  z/OS 1.10 exploits more 64-bit storage
> (GRS, SMSPDSE, TRACE, etc).  The system trace (TRACE) buffers not only
> increased from 256K to 1M per logical CP, but also moved above the 2GB bar.
>  We are experiencing very poor performance mostly during abend processing as
> described in II14465.
>
> Configuration:
> LPAR has 4GB real storage.
> 2 logical CPs
>
> In addition to z/OS, significant exploiters of 64-bit storage are:
> Four DB2 v8/v9 systems
> Three IMS v10 systems
> Four CICS Transaction Server v3.2 regions
> Two Java 1.6 (64-bit) application address spaces
>
> Regards,
> Jack Oakley
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html 
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

Re: 64-Bit Storage / Performance Issues with z/OS 1.10

[Gil Peleg]

Jack,
What value do you specify in IEASYSxx for LFAREA= ? The default is none,
which means no real storage should be used to back 1M pages. So if you are
taking the default, your problem is probably not caused by large pages.

HTH,
Gil.

On Tue, Mar 16, 2010 at 7:17 PM, Jack Oakley  wrote:

> Curious to learn if anyone else has experienced this problem and what you
> did to resolve it.
>
> Migrating from z/OS 1.9 to 1.10.  z/OS 1.10 exploits more 64-bit storage
> (GRS, SMSPDSE, TRACE, etc).  The system trace (TRACE) buffers not only
> increased from 256K to 1M per logical CP, but also moved above the 2GB bar.
>  We are experiencing very poor performance mostly during abend processing as
> described in II14465.
>
> Configuration:
> LPAR has 4GB real storage.
> 2 logical CPs
>
> In addition to z/OS, significant exploiters of 64-bit storage are:
> Four DB2 v8/v9 systems
> Three IMS v10 systems
> Four CICS Transaction Server v3.2 regions
> Two Java 1.6 (64-bit) application address spaces
>
> Regards,
> Jack Oakley
>
>
> --
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
> Search the archives at http://bama.ua.edu/archives/ibm-main.html
>

--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html

64-Bit Storage / Performance Issues with z/OS 1.10

[Jack Oakley]

Curious to learn if anyone else has experienced this problem and what you did 
to resolve it.
 
Migrating from z/OS 1.9 to 1.10.  z/OS 1.10 exploits more 64-bit storage (GRS, 
SMSPDSE, TRACE, etc).  The system trace (TRACE) buffers not only increased from 
256K to 1M per logical CP, but also moved above the 2GB bar.  We are 
experiencing very poor performance mostly during abend processing as described 
in II14465.  
 
Configuration:   
LPAR has 4GB real storage.
2 logical CPs
 
In addition to z/OS, significant exploiters of 64-bit storage are:
Four DB2 v8/v9 systems
Three IMS v10 systems
Four CICS Transaction Server v3.2 regions
Two Java 1.6 (64-bit) application address spaces
 
Regards,
Jack Oakley


--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@bama.ua.edu with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html