16K Page Benchmarks under zparm DSVCI

Jeff L'Italien

16K Page Benchmarks under zparm DSVCI
Esteemed list,

I would like to know if any of you have performed benchmarks of processing a 4K page versus that of a 16K page while zparm DSVCI is active within your corresponding subsystem. I am currently in the process of doing so and the results I have seen in regards to a possible reduction in both elapsed/CPU times is not very promising. I have tested utility processing (load/reorg/runstats....all IBM) and the associated times appears to be very similar. However, in executing a sample COBOL application performing singleton selects against each table the times actually appear to be worse against the object defined as 16K. The application program is processing an input file in which the records are ordered in clustering index sequence to maximize sequentional prefetch against each of the 2 respective tables. As the 16K page accomodates more records per page than the 4K page (both using FREEPAGE 0 PCTFREE 0) I'm wondering if the instruction path length for the 16K page may be longer than that of the 4K page which is causing the longer elapsed/CPU times. If anyone has performed similar type of testing I would be interested in knowing of your results.

Best Regards,
Jeff L'Italien
American Express

_____________________________________________________________________
* IDUG North America * Anaheim, California * May 2-6 2011 * http://IDUG.ORG/NA *
* If you are going to attend only one conference this year, this is it! *
_____________________________________________________________________
http://www.IDUG.org/mentor
Mentoring should be a rewarding experience for everyone...
IDUG is offering up to 80% off when you both come to the conference!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's Listserv

Avram Friedman

Re: 16K Page Benchmarks under zparm DSVCI
(in response to Jeff L'Italien)
In theory for sequencial operations CPU time for 16k vs 4K should be reduced. The I/O CPU is identical regardless of block . CI size.

For random singleton selects CPU for 16K might be larger than 4k if the same amout of storage is allocated to the buffer pool. As the chance of a buffer hit is reduced.

For both sequencial operations and random singleton selects I would expect no diffrence in elapsed time,
DASD control unit is going to read a cache the entire track regardless of the amout of data requested by the application code.
I/O time is strongly corolated to elapsed time.

Why go with a bigger CI or block size?
Less wasted space in the block.
Better logical insert replace performance as free space is more likly in blocks already in the buffer pool.

My comments are not DB2 specific but I/O specific.

The principal activity of data processing is processing data ... Avram's first law

Best wishes
Avram Friedman

On Wed, 5 Jan 2011 12:48:10 -0500, Jeff L'Italien <[login to unmask email]> wrote:

>Esteemed list,
>
>I would like to know if any of you have performed benchmarks of processing a 4K page versus that of a 16K page while zparm DSVCI is active within your corresponding subsystem. I am currently in the process of doing so and the results I have seen in regards to a possible reduction in both elapsed/CPU times is not very promising. I have tested utility processing (load/reorg/runstats....all IBM) and the associated times appears to be very similar. However, in executing a sample COBOL application performing singleton selects against each table the times actually appear to be worse against the object defined as 16K. The application program is processing an input file in which the records are ordered in clustering index sequence to maximize sequentional prefetch against each of the 2 respective tables. As the 16K page accomodates more records per page than the 4K page (both using FREEPAGE 0 PCTFREE 0) I'm wondering if the instruction path length for the 16K page may be longer than that of the 4K page which is causing the longer elapsed/CPU times. If anyone has performed similar type of testing I would be interested in knowing of your results.
>
>Best Regards,
>Jeff L'Italien
>American Express
>
>_____________________________________________________________________
>* IDUG North America * Anaheim, California * May 2-6 2011 * http://IDUG.ORG/NA *
>* If you are going to attend only one conference this year, this is it! *
>_____________________________________________________________________
>http://www.IDUG.org/mentor
>Mentoring should be a rewarding experience for everyone...
>IDUG is offering up to 80% off when you both come to the conference!
>_____________________________________________________________________
>
>If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's Listserv

_____________________________________________________________________
* IDUG North America * Anaheim, California * May 2-6 2011 * http://IDUG.ORG/NA *
* If you are going to attend only one conference this year, this is it! *
_____________________________________________________________________
http://www.IDUG.org/mentor
Mentoring should be a rewarding experience for everyone...
IDUG is offering up to 80% off when you both come to the conference!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's Listserv

Avram Friedman

Re: 16K Page Benchmarks under zparm DSVCI
(in response to Avram Friedman)
Here is an oldie but goodie blog posting from Willie Favero on DSVCI

http://it.toolbox.com/blogs/db2zos/kewl-db2-for-zos-v8-feature-part-3-vsam-control-interval-ci-support-8627

It contails a couple of links to performance information..
My reading is the performace advantages like in DASD usage and Write Performance.

There seems to be a few considerations not mentioned in the question like VCAT vs STOGROUP defined.

At some time in my life I learned a concept called the scientific method
As I recall there were 4 ordered steps
Hypothesize
Research
Experiment
Analysis

At least by this old standard there might be a missing step in this study.

Best Wishes
Avram Friedman

On Wed, 5 Jan 2011 12:48:10 -0500, Jeff L'Italien <[login to unmask email]> wrote:

>Esteemed list,
>
>I would like to know if any of you have performed benchmarks of processing a 4K page versus that of a 16K page while zparm DSVCI is active within your corresponding subsystem. I am currently in the process of doing so and the results I have seen in regards to a possible reduction in both elapsed/CPU times is not very promising. I have tested utility processing (load/reorg/runstats....all IBM) and the associated times appears to be very similar. However, in executing a sample COBOL application performing singleton selects against each table the times actually appear to be worse against the object defined as 16K. The application program is processing an input file in which the records are ordered in clustering index sequence to maximize sequentional prefetch against each of the 2 respective tables. As the 16K page accomodates more records per page than the 4K page (both using FREEPAGE 0 PCTFREE 0) I'm wondering if the instruction path length for the 16K page may be longer than that of the 4K page which is causing the longer elapsed/CPU times. If anyone has performed similar type of testing I would be interested in knowing of your results.
>
>Best Regards,
>Jeff L'Italien
>American Express
>
>_____________________________________________________________________
>* IDUG North America * Anaheim, California * May 2-6 2011 * http://IDUG.ORG/NA *
>* If you are going to attend only one conference this year, this is it! *
>_____________________________________________________________________
>http://www.IDUG.org/mentor
>Mentoring should be a rewarding experience for everyone...
>IDUG is offering up to 80% off when you both come to the conference!
>_____________________________________________________________________
>
>If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's Listserv

_____________________________________________________________________
* IDUG North America * Anaheim, California * May 2-6 2011 * http://IDUG.ORG/NA *
* If you are going to attend only one conference this year, this is it! *
_____________________________________________________________________
http://www.IDUG.org/mentor
Mentoring should be a rewarding experience for everyone...
IDUG is offering up to 80% off when you both come to the conference!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's Listserv

Daniel Luksetich

Re: 16K Page Benchmarks under zparm DSVCI
(in response to Avram Friedman)
I myself have performed benchmarks of 4K versus 8K and have had similar (yawn) results. So far I have not defined any objects on z/OS that are using larger page sizes unless they have very long rows
Dan

Daniel L Luksetich
IBM Information Champion
IBM Certified Database Administrator - DB2 10 for z/OS
IBM Certified System Administrator - DB2 9 for z/OS
IBM Certified Solutions Expert - DB2 Universal Database V7.1 Database Administration for UNIX, Windows, and OS/2
IBM Certified Solutions Expert - DB2 UDB V7.1 Family Application Development
IBM Certified Advanced Technical Expert - DB2 Data Replication

Vice President of Global Database Operations
YL&A, Inc.
Database Performance Professionals
http://www.ylassoc.com
http://www.db2expert.com
http://www-01.ibm.com/software/data/champion/profiles/luksetich.html



-----Original Message-----
From: IDUG DB2-L [mailto:[login to unmask email] On Behalf Of Avram Friedman
Sent: Wednesday, January 05, 2011 3:44 PM
To: [login to unmask email]
Subject: [SPAM] Re: 16K Page Benchmarks under zparm DSVCI

In theory for sequencial operations CPU time for 16k vs 4K should be reduced. The I/O CPU is identical regardless of block . CI size.

For random singleton selects CPU for 16K might be larger than 4k if the same amout of storage is allocated to the buffer pool. As the chance of a buffer hit is reduced.

For both sequencial operations and random singleton selects I would expect no diffrence in elapsed time,
DASD control unit is going to read a cache the entire track regardless of the amout of data requested by the application code.
I/O time is strongly corolated to elapsed time.

Why go with a bigger CI or block size?
Less wasted space in the block.
Better logical insert replace performance as free space is more likly in blocks already in the buffer pool.

My comments are not DB2 specific but I/O specific.

The principal activity of data processing is processing data ... Avram's first law

Best wishes
Avram Friedman

On Wed, 5 Jan 2011 12:48:10 -0500, Jeff L'Italien <[login to unmask email]> wrote:

>Esteemed list,
>
>I would like to know if any of you have performed benchmarks of processing a 4K page versus that of a 16K page while zparm DSVCI is active within your corresponding subsystem. I am currently in the process of doing so and the results I have seen in regards to a possible reduction in both elapsed/CPU times is not very promising. I have tested utility processing (load/reorg/runstats....all IBM) and the associated times appears to be very similar. However, in executing a sample COBOL application performing singleton selects against each table the times actually appear to be worse against the object defined as 16K. The application program is processing an input file in which the records are ordered in clustering index sequence to maximize sequentional prefetch against each of the 2 respective tables. As the 16K page accomodates more records per page than the 4K page (both using FREEPAGE 0 PCTFREE 0) I'm wondering if the instruction path length for the 16K page may be longer than that of the 4K page which is causing the longer elapsed/CPU times. If anyone has performed similar type of testing I would be interested in knowing of your results.
>
>Best Regards,
>Jeff L'Italien
>American Express
>
>_____________________________________________________________________
>* IDUG North America * Anaheim, California * May 2-6 2011 * http://IDUG.ORG/NA *
>* If you are going to attend only one conference this year, this is it! *
>_____________________________________________________________________
>http://www.IDUG.org/mentor
>Mentoring should be a rewarding experience for everyone...
>IDUG is offering up to 80% off when you both come to the conference!
>_____________________________________________________________________
>
>If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's Listserv

_____________________________________________________________________
* IDUG North America * Anaheim, California * May 2-6 2011 * http://IDUG.ORG/NA *
* If you are going to attend only one conference this year, this is it! *
_____________________________________________________________________
http://www.IDUG.org/mentor
Mentoring should be a rewarding experience for everyone...
IDUG is offering up to 80% off when you both come to the conference!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's Listserv
No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.872 / Virus Database: 271.1.1/3357 - Release Date: 01/04/11 13:34:00

_____________________________________________________________________
* IDUG North America * Anaheim, California * May 2-6 2011 * http://IDUG.ORG/NA *
* If you are going to attend only one conference this year, this is it! *
_____________________________________________________________________
http://www.IDUG.org/mentor
Mentoring should be a rewarding experience for everyone...
IDUG is offering up to 80% off when you both come to the conference!
_____________________________________________________________________

If you need to change settings, http://www.idug.org/cgi-bin/wa?A0=DB2-L is the home of IDUG's Listserv