Wednesday, December 18, 2013

DB2 for z/OS: Monitoring Prefetch Read Activity

Not long ago, a colleague sent to me some DB2 for z/OS buffer pool activity data that a DB2-using organization had sent to him. The DB2 people at this site were alarmed by some of the prefetch-related numbers in the data, and they had requested a review of the information. My analysis of the figures suggested that the system administrators were concerned by numbers that were in fact positive in nature; however, I also saw prefetch items that really were troublesome, and I subsequently learned that these were likely due to a buffer pool configuration change that had been made to improve application performance but ended up working towards the opposite end. In this blog entry I'll explain why buffer pool statistics related to prefetch activity are sometimes misinterpreted, and how "tuning" actions intended to bolster synchronous read performance can have unexpectedly negative consequences.

First, the misinterpreted figures. A system administrator at the aforementioned DB2 for z/OS site was doing a good thing: reviewing the output of the DB2 command -DISPLAY BUFFERPOOL(bpname) DETAIL for two of the key buffer pools allocated in a production subsystem. He calculated some ratios, and was particularly concerned about a couple of the calculated values. For both of the pools, the ratio of pages read via dynamic prefetch to the number of dynamic prefetch requests was quite low: about 2 to 1 for one pool, and only 0.13 to 1 for the other pool. This had the appearance to the system administrator of something being not right, as he knew that a dynamic prefetch request would generally be for 32 pages.

In fact, these dynamic prefetch requests versus pages read via dynamic prefetch numbers were just fine, but they are often viewed incorrectly. One factor that contributes to these incorrect readings of -DISPLAY BUFFERPOOL data is the fact that many people look at prefetch requests when they should be focusing instead on prefetch I/Os. The really important thing to understand here is this: a prefetch request is just that: a request to read from disk a particular set of pages (typically 32 contiguous table space or index pages in the case of dynamic prefetch). If all of the pages associated with a prefetch request are already in the buffer pool, the prefetch request will not result in a prefetch I/O. What that should tell you is, a high ratio of prefetch requests to prefetch reads is a good thing -- it means that pages are being effectively cached in the buffer pool, so that when a chunk of said pages is asked for by way of a prefetch request, an associated I/O will often not be necessary because all of the pages in the prefetch request are already in memory. Sure, a prefetch I/O will often be preferred to a synchronous I/O, because the latter always results in application wait time, while in the case of the former it is hoped that the prefetch I/O operation will complete before the application process (the one on behalf of which the I/O is being driven) asks for rows (or index entries, as the case may be) from the pages being read from disk. Even so, however, a "non-I/O" is preferable versus a prefetch I/O.

Pages read via prefetch, then, should be compared to prefetch I/Os, not to prefetch requests. Looked at in that light, pages read via dynamic prefetch for the buffer pools of interest here might still appear to be on the low side: about 13 pages per prefetch I/O for the one buffer pool and about 14 pages per prefetch I/O for the other pool. It would be better if those figures were closer to 32, the size of a typical dynamic prefetch request, right? WRONG. It's the same thing as a high ratio of prefetch requests to prefetch read I/Os: fewer pages read into memory per prefetch I/O is a good thing. It means that (again) pages are being effectively cached in the buffer pool, so that when a prefetch request for 32 pages (for example) is issued, far fewer than 32 pages will have to be read into memory from disk because close to 20 of those 32 pages (on average for these particular buffer pools during a particular time period) are already in the buffer pool.

Thus it is that the high ratio of dynamic prefetch requests to dynamic prefetch read I/Os seen by the system administrator for the two buffer pools in his DB2 system, and the low ratio of pages read via dynamic prefetch to dynamic prefetch read I/Os, are not "uh-oh" numbers -- they are "Yes!" numbers. At the same time, however, there were indeed some "uh-oh" numbers in the -DISPLAY BUFFERPOOL output that caught my eye. Specifically, I saw that prefetch had been disabled for one of the pools, due to a lack of buffer resources, 164 times during the 28 minutes of activity captured in the command output. [The output of -DISPLAY BUFFERPOOL DETAIL contains a timestamp for each buffer pool listed, showing the start of the activity-capture time period (the end of the period is the time at which the command was issued). This timestamp will indicate either the time at which a pool was last allocated, or when the -DISPLAY BUFFERPOOL command was previously and most recently issued for the pool; so, if the command is issued once for a pool and then issued again for the pool an hour later, the timestamp value in the output of the second issuance of the command will be one hour before the time at which the command was issued for the second time.] That's not good. Because prefetch reads, when appropriate, are generally preferred over synchronous reads (this because, as previously mentioned, they are "anticipatory" reads, intended to bring pages into memory before they are needed by an application process), you really don't want to see prefetch disabled because of a shortage of buffers available to support prefetch reads.

Why would there be such a buffer shortage for this pool? I had a suspicion, and that was confirmed when I saw that the sequential threshold for the pool (also known as VPSEQT, short for the virtual pool sequential threshold) was set at 25, versus the default value of 80. What did that mean? It meant that instead of the usual 80% of the pool's buffers being available to hold pages brought into memory via prefetch, only 25% of the buffers were available for this purpose (the other 75% of the buffers in the pool were reserved exclusively for pages read into memory via synchronous reads). Why had the sequential threshold been lowered for the pool? The thinking had been that this action would reduce synchronous read activity (and we like to reduce that because, as I pointed out, a synchronous read always involves application wait time) by providing more synchronous-read-only buffers in the pool. Sounds logical, right? And, it might have had the desired effect if there hadn't been a lot of prefetch requests for the pool. In fact, there were more than 800 prefetch requests per second for this pool, and dramatically reducing the buffer resources available to support prefetch I/Os associated with the prefetch requests ended up negatively impacting synchronous read activity -- precisely the opposite of the hoped-for effect.

Here's the connection between a non-zero value for PREFETCH DISABLED - NO BUFFER in -DISPLAY BUFFERPOOL output and synchronous read activity: when prefetch is disabled, the pages that would have been read into memory via a prefetch read I/O will likely still be sitting on disk when an application process needs them. What happens then? They are synchronously read into the buffer pool (while the application process waits). Thus, incidents of prefetch being disabled can increase synchronous read activity; furthermore, with far fewer buffers (versus the default) in this pool being available for holding prefetch-read pages, pages that had been brought into memory via prefetch were quickly being flushed out of the pool to make room for other prefetch-read pages, and that meant that they couldn't be re-referenced without driving more I/Os, and that also worked to drive up synchronous read activity for the pool.

So, I told these folks (through their local IBM technical specialist) to significantly increase the VPSEQT setting for this buffer pool, and explained the rationale behind the recommendation. They ended up changing the sequential threshold for the pool back to the default value of 80. The results (shown in the buffer pool section of a DB2 monitor statistics long report for the DB2 subsystem) were quite positive and, I think, interesting: the frequency of prefetch being disabled due to a lack of buffer resources went from about 6 per minute to zero, and synchronous read activity dropped by 43%, even though the percentage of the pool's buffers set aside exclusively for synchronous reads went from 75% to 20%. With the VPSEQT change, more pages could be read into memory in an anticipatory fashion, and those pages, once prefetched into the pool, were likely to stay resident in the pool for a longer period of time, and the combination of these effects reduced the need to synchronously read pages from disk.

Here are what I see as the key take-aways from this case:
  • Do not discount the importance of prefetch reads. Some DB2 for z/OS people are overly focused on synchronous read activity, to the point that they will do things that negatively impact prefetch read operations for a buffer pool. That can be a mistake, leading in some cases to increased synchronous read activity.
  • Be careful about reducing VPSEQT for a buffer pool. Such an adjustment might have an overall positive performance impact for a pool that has relatively little prefetch activity. Here, I'd look at the volume of prefetch requests (sequential, list, and dynamic) per second for the pool of interest. If that number is high (e.g., hundreds or more per second), DB2 has determined that asynchronous reads are the right choice for bringing many of the pages of objects assigned to the pool that are needed by programs into memory. If you squeeze down the resources with which DB2 can work in servicing prefetch requests, the result could be an undesirable increase in synchronous read activity. Even if you do think that you have a pool for which a lowering of the VPSEQT setting could be beneficial, don't go overboard. Don't change from VPSEQT=80 to some much-lower value in one fell swoop -- make more modest adjustments to VPSEQT and monitor results as you go along.
  • Monitor buffer pool activity in an ongoing fashion, using information from your DB2 monitor and/or the output of the -DISPLAY BUFFERPOOL DETAIL command (a form of this command that I like to use is -DISPLAY BUFFERPOOL(ACTIVE) DETAIL, and I like to issue that command once and then again in an hour to have an hour's worth of activity captured in the output of the second issuance of the command). Look for incidents of PREFETCH DISABLED - NO BUFFER and PREFETCH DISABLED - NO READ ENGINE (the latter can also be related to a lack of buffer resources, if that lack of resources leads to elevated levels of prefetch read I/O activity). If you see non-zero values in these fields for a buffer pool, first check the VPSEQT value for the pool, and consider changing that value to 80 if it is less than 80. If you already have VPSEQT=80 for the pool, consider making the pool larger, if you have the real storage in the z/OS LPAR to back a larger pool.

If you're a DB2 person, prefetch is your friend. Don't hobble it.

8 comments:

  1. Hi Robert,
    Very interesting article .
    I would like to ask your opinion.
    We have interesting situation . By monitoring Bufferpool activity , I found that whenever we hit Prefetch disabled - No buffer condition , the number of such conditions is always equal to number of Sequential prefetch requests. So, none of Sequential prefetch requests gets scheduled , while Dynamic requests still get processes.
    This happens only for Bufferpools strictly allocated for index usage , eiher 4K or 8K buffers, doesnt make a difference. Also VPSEQT threshold doesnt seem to matter, since values vary from 30% to 80%. It never happens in Bufferpools allocated for tablespace usage.
    I really appreciate your opinion on this situation .

    Regards Ilya

    ReplyDelete
    Replies
    1. I do not know why you are seeing this. My understanding has been that sequential prefetch usage for indexes virtually disappeared starting with DB2 9 (with DB2 9 sequential prefetch is still used for table space scans). You might need to call the IBM Support Center to get this mystery resolved.

      Robert

      Delete
  2. Hi Robert,
    Recently, we started experiencing very high numbers in Prefetch- No Engines condition . sometimes it runs as high as over 100 events per second. I noticed delays in applcation jobs - Class 3 other read i/o time. Some jobs just stalled for minutes waiting for Prefetch engines to be available . This condition happens for several different buffers.
    My thresholds (VPSEQT) in range of 80-85% , size of buffers varies from 40,000 to 100,000 pages.
    I have a question, since in ver 10 Prefetch engines z/IIP eligible , could be the cause of Prefetch engines to be unvailable becuase of z/IIP not configured properly or not enough z/IIP engines available ?
    Regards Ilya

    ReplyDelete
    Replies
    1. Yes, in a DB2 10 (or 11) for z/OS environment, zIIP engine contention can negatively impact prefetch performance. I wrote a blog entry on this topic a few months ago (the URL for that entry is http://robertsdb2blog.blogspot.com/2014/09/db2-for-zos-avoiding-ziip-engine.html).

      If you can augment your zII{P capacity, great. If you can't do that (or can't do it soon), and if your z Systems server's real storage resource is not under too much pressure (i.e., if the demand paging rate for the LPAR in question is in the low single digits per second or less), you could try enlarging the buffer pools that have the largest amount of prefetch activity, so as to try to reduce the number of prefetch read I/Os for those pools.

      You could also see if you can identify particular programs that are driving lots of prefetch reads, and then see if access paths for SQL statements issued by those programs could be changed so as to reduce prefetch read activity -- perhaps by adding a few new indexes and/or adding columns to existing indexes.

      Robert

      Delete
  3. Hi Robert,

    I've been reviewing our prefetch statistics, and for many time periods I'm seeing relatively high I/O to pages read ratios, sometimes as high as 127 pages per I/O. Our VPSEQT for these pools is 20. I was considering increasing that, to 40 as a first stroke. Would you recommend that, or is there a factor (similar to the data that prompted this blog) that I'm not seeing that would counter indicate such a change?

    Thanks,
    Don

    ReplyDelete
    Replies
    1. Could you clarify a bit, Don? What two fields, from what source (e.g., a DB2 monitor report, DB2 -DISPLAY BUFFERPOOL output, or something else), are you using to arrive at your 127-to-1 ratio?

      Robert

      Delete
  4. I'm not using -DISPLAY BUFFERPOOL directly, but rather the SMF fields that correspond to the 'PREFETCH I/O' and 'PAGES READ' fields of the display command. We have a BMC product that extracts and formats SMF data and I'm using the QBSTPIO field for 'PREFETCH I/O' and QBSTSPP for 'PAGES READ'. From comparisons to actual DISPLAY BUFFERPOOL commands I believe these are the correct SMF fields.

    Don

    ReplyDelete
    Replies
    1. Well, the 127-to-1 ratio of pages read via sequential prefetch to sequential prefetch read I/Os that you are seeing is about double the highest figure I've ever seen. It could certainly be that high theoretically, but based on what I know it would require most all of the reads to be associated with the execution of DB2 utilities. If a buffer pool has enough buffers that can be occupied by pages read into memory via prefetch (that is, if VPSIZE for the pool times the pool's VPSEQT setting - with the latter expressed as a percentage - is at least 80,000) then a utility can read up to 128 pages per sequential prefetch read I/O. That being the case, if you were looking at data for a pool for which associated objects (or partitions thereof) were 1) almost entirely not in memory initially and 2) processed by one or more DB2 utilities, you could see a ratio close to 128 pages read per sequential prefetch I/O. Would that be indicative of a problem? Not necessarily. If objects processed by DB2 utilities were entirely not in memory when the utility processing began, a larger VPSEQT specification might not change the situation. I do think that 20 is quite low for a VPSEQT setting, but if the large majority of GETPAGEs for the pool are random in nature, and the number of prefetch read I/Os (sequential, list, and dynamic) is much smaller than the number of synchronous read I/Os, and you don't see indications that prefetch is being disabled due to a lack of buffers or a lack of prefetch read engines, a relatively low VPSEQT specification might be OK.

      If you want, you can use information in -DISPLAY BUFFERPOOL(BPn) DETAIL command output to double check the numbers provided by your DB2 monitor (if the command is issued at time X and again at time Y, the statistics in the output of the second issuance of the command will reflect activity between times X and Y). If you see a major discrepancy, it could be that your monitor is incorrectly reporting on buffer pool activity.

      Robert

      Delete