DB2 9 for z/OS: Buffer Pool Monitoring and Tuning - IBM Redbooks

More documents

Recommendations

Info

So by choosing a value for F, it is a simple calculation to derive a value for VPSEQT. This formula will work best for those pools where the buffer pool size is much smaller than the sum of all pages of all objects assigned to that pool and should not be used for data in memory, sort/work, or pools for objects needing customized settings. One other important consideration for VPSEQT is the effect on prefetch quantity when using DB2 9. The increase in prefetch size for sequential prefetch and list prefetch for LOBs from 32 to 64 for the 4 KB pools applies when: VPSIZE * VPSEQT >= 40,000 With the default of 80% you would need to have a pool of at least 50,000 pages. If VPSEQT was halved to 40%, then the size would need to be 100,000 pages to get this benefit. Furthermore, the increase from 64 to 128 pages for utility sequential prefetch for the 4 KB pools applies when: VPSIZE * VPSEQT >= 80,000 So with the default of 80% you would need to have a pool of at least 100,000 pages. If VPSEQT was halved to 40%, then the size would need to be 200,000 pages to get this benefit. Note that these increases do not apply to dynamic prefetch nor to non-LOB list prefetch. Setting VPSEQT=0 disables the initiation of all prefetch engines as discussed in the section on using a pool for data in memory objects; however, this setting also disables parallelism. Vertical Deferred Write Queue Threshold (VDWQT) The purpose of this parameter is to trigger the writing of updated pages out of the buffer pool to disk storage. Unlike the DWQT, where the default of 30% is a good starting point, the choice of VDWQT is more complex because it is dependent on the workload. The recommendation is to start with a default setting of 5% and then adjust according to the following factors. Increase the value for: ► In-memory index or data buffer pools ► Fewer pages written per unit of time ► Reduced frequency of same set of pages written multiple times ► Reduced page latch contention (when page is being written, first update requestor waits on “other write I/O”, subsequent updaters wait on page latch). The page latch suspension time is reported in the field PAGE LATCH in the accounting report. ► Reduced forced log writes (log records must be written ahead of updated pages) ► Random insert, update, or delete operations Decrease the value for: ► Reduced total of updated pages in pool so more buffers are available for stealing ► Reduce burst of write activity at checkpoint intervals ► More uniform and consistent response time ► Better performance of the buffer pool as a whole when writes are predominantly for sequential or skip sequential insert of data ► For data sharing, free page p-lock sooner, especially NPI index page p-lock 14 DB2 9 for z/OS: Buffer Pool Monitoring and Tuning
To page fix or not to page fix The recommendation is to use long term page fix (PGFIX=YES) for any pool with a high buffer I/O intensity. The buffer intensity can be measured by: Buffer Intensity = (pages read + pages written) / buffer pool size where: pages read = total number of pages read in a given statistics interval, including synchronous read and sequential, dynamic and list prefetch. (trace fields QBSTRIO + QBSTSPP + QBSTDPP + QBSTLPP) pages written = total number of pages written in a given statistics interval including synchronous write and deferred write. (trace field QBSTPWS) It cannot be emphasized too strongly that using PAGEFIX=YES has to be agreed with whomever manages the z/OS storage for the LPAR, because running out of storage can have catastrophic effects for the whole of z/OS. It is worth remembering that any pool where I/O is occurring will utilize all the allocated storage. This is why the recommendation is to use PGFIX=YES for DB2 V8 and above for any pool where I/Os occur, provided all virtual frames above and below the 2 GB bar are fully backed by real memory and DB2 virtual buffer pool frames are not paged out to auxiliary storage. If I/Os occur and PGFIX=NO then it is possible that the frame will have been paged out to auxiliary storage by z/OS and therefore two synchronous I/Os will be required instead of one. This is because both DB2 and z/OS are managing storage on a least recently used basis. The number of page-ins for read and write can be monitored either by using the DISPLAY BUFFERPOOL command to display messages DSNB411I and DSNB420I or by producing a Statistics report. There is also a CPU overhead for PGFIX=NO because DB2 has to fix the page in storage before the I/O and unfix afterwards. Some customers have seen measurable reductions in CPU by setting PAGEFIX=YES, hence the general recommendation is to use YES for this parameter. Note PGFIX=YES is also applicable to GBP reads and writes. The disadvantage of PGFIX=YES is that the page cannot be paged out under any circumstances. This could cause paging to occur on other applications to their detriment should a need arise for a large number of real frames, such as during a dump. Measurement No tuning should be attempted until a solid base of reliable data is available for comparison. The simplest measures are the getpage and I/O rates. The number of getpages per second is a measure of the amount of work being done. If the intention is to reduce I/O, then by measuring the getpages per I/O before and after any change, an estimate can be made of the number of I/Os saved. Another metric is the wait time due to synchronous I/O, which is tracked in the accounting trace data class 3 suspensions. The CPU cost of synchronous I/O is accounted to the application and so the CPU is normally credited to the agent thread. However, asynchronous I/O is accounted for in the DB2 address space DBM1 SRB measurement. The DB2 address space CPU consumption is reported in the DB2 statistics trace which can be captured and displayed by a tool such as IBM Tivoli OMEGAMON XE for DB2 Performance Monitor on z/OS. DB2 9 for z/OS: Buffer Pool Monitoring and Tuning 15
Page 1 and 2: Redpaper DB2 9 for z/OS: Buffer Poo
Page 3 and 4: A getpage is one of three types:
Page 5 and 6: Assuming that the page is neither i
Page 7 and 8: The second threshold is the vertica
Page 9 and 10: threshold is not actually being hit
Page 11 and 12: Tuning recommendations We now exami
Page 13: issue during times of needing large
Page 17 and 18: Appendix A - Results from customer
Page 19 and 20: 50 5 756 697 34 8800 8273 39 9556 8
Page 21 and 22: Appendix B - Sample DISPLAY BUFFERP
Page 23 and 24: Appendix D - Hit ratio and system p
Page 25 and 26: *(A.SYNC_READ_IO+A.SEQ_PREFETCH_PAG
Page 27 and 28: ► ► ► DB2 Version 9.1 for z/O
Page 29 and 30: Notices This information was develo

DB2 9 for z/OS: Buffer Pool Monitoring and Tuning - IBM Redbooks

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

Delete template?

Save as template?