19.06.2013 Views

DB2 UDB for z/OS Version 8 Performance Topics - IBM Redbooks

DB2 UDB for z/OS Version 8 Performance Topics - IBM Redbooks

DB2 UDB for z/OS Version 8 Performance Topics - IBM Redbooks

SHOW MORE
SHOW LESS

You also want an ePaper? Increase the reach of your titles

YUMPU automatically turns print PDFs into web optimized ePapers that Google loves.

4.5.1 Per<strong>for</strong>mance<br />

The most buffer pools <strong>DB2</strong> allows you to page fix are up to 80% of the real storage of the<br />

z/<strong>OS</strong> LPAR. This limitation is in place to protect other workloads on the LPAR from being<br />

“squeezed” by <strong>DB2</strong>.<br />

We tested the impact of long term page fixing all of our buffer pools, both in a data sharing<br />

and non-data sharing environment. We used the same IRWW workload <strong>for</strong> both tests. We<br />

also used an I/O intensive workload, by limiting the storage used by the buffer pools to 400<br />

MB.<br />

Let us first look at non-data sharing. Table 4-9 compares PGFIX(NO) to PGFIX(YES) in a<br />

non-data sharing test.<br />

Table 4-9 Long term page fix - non-data sharing<br />

PGFIX NO YES Delta<br />

(YES/NO)<br />

DBM1<br />

(msec / commit)<br />

Total <strong>DB2</strong> CPU time<br />

(msec / commit)<br />

ITR<br />

(msec / commit)<br />

Page fixing <strong>DB2</strong> buffer pools has a significant positive impact on per<strong>for</strong>mance. We can see<br />

almost a 30% reduction in CPU consumed by the DBM1 address space per transaction. This<br />

is because prefetch requests and deferred write I/O requests stand to benefit the most from<br />

page fixing. <strong>DB2</strong> no longer has to page fix a large number pages be<strong>for</strong>e initiating each<br />

prefetch and write I/O request. <strong>DB2</strong> also does not have to release the pages after the I/O has<br />

completed. <strong>DB2</strong> only incurs the cost of page fixing when the buffer pool page is first<br />

referenced in an I/O request. Subsequent I/Os do not incur this cost again.<br />

We can also see a 8% reduction in total CPU time used by <strong>DB2</strong> and a gain of 6% in<br />

transaction throughput.<br />

Now let us have a look at data sharing. Table 4-10 compares PGFIX(NO) to PGFIX(YES) in a<br />

data sharing environment with two members. Notice that a long term page fix applies to GBP<br />

read and write. It does not apply to castout work area, since cast work area is not a part of<br />

buffer pool and a long term page fix is a buffer pool option.<br />

Table 4-10 Long term page fix - data sharing<br />

170 <strong>DB2</strong> <strong>UDB</strong> <strong>for</strong> z/<strong>OS</strong> <strong>Version</strong> 8 Per<strong>for</strong>mance <strong>Topics</strong><br />

0.455 0.322 -29%<br />

2.436 2.238 -8%<br />

587.22 601.42 +6%<br />

PGFIX NO YES Delta<br />

(YES / NO)<br />

DBM1<br />

(msec / commit)<br />

Total <strong>DB2</strong> CPU time<br />

(msec / commit)<br />

Group ITR<br />

(commit / sec)<br />

0.560 0.563 0.456 0.457 -19%<br />

3.318 3.306 3.109 3.357 -2%<br />

890.70 897.00 +1%

Hooray! Your file is uploaded and ready to be published.

Saved successfully!

Ooh no, something went wrong!