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.

The EXTENDED REGION SIZE (MAX) is the size of the region available to <strong>DB2</strong> after MVS<br />

has allocated all common ECSA, ELPA, and ENUC type storage. It is commonly thought that<br />

<strong>DB2</strong> has 2 GB available, but this is generally more in the range of 1000 MB - 1600 MB. Most<br />

of the storage <strong>DB2</strong> allocates below the bar is here, in MVS subpool 229 or 230 key 7.<br />

The general recommendation <strong>for</strong> monitoring and tuning <strong>DB2</strong> storage is to have approximately<br />

200 MB free <strong>for</strong> fluctuations in workload. This recommendation is also true <strong>for</strong> <strong>DB2</strong> V8. 200<br />

MB is a good conservative number, but you may think of reducing this if your <strong>DB2</strong> subsystem<br />

is small.<br />

The EXTENDED CSA SIZE is the common storage area across all address spaces <strong>for</strong> a<br />

given LPAR. A large ECSA allocation would be .5 to .8 GB, while a typical allocation would be<br />

.3 to .5 GB.<br />

MVS is very likely to report a different number in EXTENDED REGION SIZE (MAX) by as<br />

much as 100 MB higher (the difference is in MVS overhead that <strong>DB2</strong> cannot track.)<br />

When <strong>DB2</strong> thinks it is running low on extended virtual storage, <strong>DB2</strong> begins a process called<br />

“system contraction”, which attempts to freemain any available segments of storage in fixed<br />

and variable pools back to MVS. (This process can be CPU-intensive and cause latch<br />

contention). If the storage <strong>DB2</strong> has reserved based on the number of threads that are allowed<br />

in the system, plus the storage <strong>DB2</strong> has reserved <strong>for</strong> open and close of data sets based on<br />

DSMAX, plus the storage <strong>DB2</strong> has reserved <strong>for</strong> must complete operations (such as ABORT<br />

and COMMIT), is less than <strong>DB2</strong>’s opinion of what storage is available, then contraction<br />

occurs.<br />

There<strong>for</strong>e, it is important to correctly estimate CTHREAD, MAXDBAT and DSMAX, and not<br />

be overly specific in estimating them.<br />

Storage estimates <strong>for</strong> threads<br />

The following <strong>for</strong>mulas apply to storage between the 16 MB line and the 2 GB bar.<br />

The current <strong>for</strong>mula <strong>for</strong> the Thread Footprint (TF) is as follows:<br />

( TOTAL VARIABLE STORAGE - TOTAL AGENT SYSTEM STORAGE / TOTAL NUMBER OF ACTIVE USER<br />

THREADS<br />

(153.39 - 3.54) / 500 = 0.2997<br />

This value is also reported in the report as AVERAGE THREAD FOOTPRINT as 0.30 MB.<br />

The fixed amounts of storage within the DBM1 address space do not vary a great deal as<br />

workload increases. They can be considered as a fixed overhead, <strong>for</strong> example, buffer pools,<br />

EDM pool, buffer pool control blocks and compression dictionaries. The total fixed storage<br />

overhead (F) can be estimated as:<br />

or<br />

TOTAL GETMAINED STORAGE + TOTAL GETMAINED STACK STORAGE + TOTAL FIXED STORAGE + 31 BIT<br />

EXTENDED LOW PRIVATE<br />

599.18 + 26.77 + 0.30 + 24.64 = 650.89 MB<br />

The value V <strong>for</strong> upper limit variable areas is defined as:<br />

V = R - C - F<br />

where:<br />

► R is the theoretical maximum region size<br />

162 <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>

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

Saved successfully!

Ooh no, something went wrong!