By Jim Damon
The DKUPDTWT parameter, new in Version 3.2.1, introduces a mechanism for delaying the DISK UPDATE process for a number of seconds, which can cause a significant reduction in the number of physical writes (DKWR ) in systems with even a small amount of update activity.
The M204.0440: DISK UPDATE COMPLETED message is generated whenever all updated pages have been written back to disk for a particular file. This always occurs when the last updating user issues a COMMIT, and no other update transactions are pending against a particular file. If, after these writes (DKWRs) have completed, the same pages are immediately updated again and written to disk, the first dkwrs have been, in a sense, wasted. In addition to this extra I/O, the file's UPDATE resource is tied up in SHR mode during the DISKUPDATE process preventing new update transactions from starting until all the dkwrs have completed. If the DISK UPDATE process could be delayed and updated pages written less frequently, the unnecessary DKWRs could be dramatically reduced and the length of time that the UPDATE resource is held could also be reduced.
The DKUPDTWT parameter lets the system manager set the wait time, in seconds, between the last COMMIT and the beginning of the DISK UPDATE process. A good starting value for this parameter is 10 seconds. Setting the DKUPDTWT parameter to 10 prevents the writing of updated pages, for each file, for up to 10 seconds following the last COMMIT.
Once the DISK UPDATE process does begin, however, it can be aborted at any time if a new update transaction attempts to start. This situation generates the m204.0440: DISK UPDATE ABORTED message.
If you set the parameter too high, a large backlog of updated pages might accumulate in the buffer pool with a subsequent increase in waiting for free buffers and an increase in checkpoint timeouts. To prevent this, set the LDKBMWND parameter to about 1/2 the size of NUMBUF. LDKBMWND sets the size of the anticipatory write window. Whenever an updated page enters this window, it is written back to the file it came from, regardless of DKUPDTWT, and the backlog of updated pages is avoided.
At least one customer reports a 99% reduction in DKWRs for one file after setting this parameter to 5 in a production online environment. DKWRs dropped from roughly 300,000 per day to about 1000 for one particular file. The customer believes that other files were also positively affected.
This parameter is especially effective in BATCH204 applications where multiple User Language requests are run serially in one job. Each END statement is an implied COMMIT and, in a BATCH204 environment, all updated pages must be written before the next request can begin. Setting theDKUPDTWT parameter to 1 in a BATCH204 job can, in some cases, improve turnaround time by orders of magnitude by eliminating waits for the DISK UPDATE process and dramatically reducing DKWRs, which, in this environment, are synchronous.
Last Modified: 03:09pm , November 11, 1996
Contact CCA Webmaster Copyright 2008
