DB2 Versions 10.1 Fix Pack 5 (APAR IT05851), 10.5 Fix Pack 7
(IT06005), and 11.1 GA introduced a behavior change in the way
asynchronous write time is accumulated. Asynchronous writes are
submitted in large batches using asynchronous I/O services/APIs
provided by an operating system. The approximate previous
behavior apportioned a pagecleaner EDU's I/O wait time evenly
across all pages in a batch. For example, if a batch of 10 I/O
requests took 10ms to complete, each I/O request/page write
would be assigned 1ms of the overall 10ms time.
In many cases the apportionment approach masks underlying
response time issues, and a change was made in the
above-mentioned DB2 levels to stop splitting a pagecleaner's
wait time across all pages written, and instead assign the
entire batch time to each page write request. In the case where
a batch of 10 I/O requests took 10ms to complete each "page
write" would be assigned the full 10ms. While there is some
value in providing this information, as it may more accurately
reflect I/O response time in some storage configurations, it can
also cause unnecessary concern. This is due to the much higher
calculated average asynchronous page write time, which bubbles
up to overall average page write time. It is reasonable that a
large batch of I/Os may incur some overhead and take longer than
a single I/O, thus the higher reported time may not be a good
indicator of underlying I/O performance. In addition, the wait
time for pagecleaner write activity does not typically impact
the time a db2agent EDU spends servicing application requests.
As such, this APAR fix will revert to the former behaviour of
splitting pagecleaner I/O wait time across the pages involved in
a batch of asynchronous I/O requests. |
