Dirty Page

Enhanced Definition

A **dirty page** in z/OS refers to a 4KB block of virtual storage that resides in real storage (main memory) and has been modified by a program or the system since it was last read from or written to auxiliary storage. It signifies that the version of the data in real storage is different from the version on disk, requiring it to be written back to auxiliary storage to maintain data integrity and free up real storage. A **dirty page** refers to a page of virtual storage that resides in real storage (main memory) and has been modified by a program or the operating system since it was last read from or written to auxiliary storage (e.g., a paging dataset on DASD). It is considered "dirty" because its content in real storage no longer matches the copy on auxiliary storage, meaning the changes have not yet been made permanent on disk.

Key Characteristics

- Modified State: The page's content in real storage has been altered, making it inconsistent with its copy on auxiliary storage.
- Real Storage Residency: A dirty page always resides in real storage (main memory) until it is written out.
- Page-Out Candidate: Dirty pages are prime candidates for the z/OS Paging Supervisor to "page out" (write to a page dataset on auxiliary storage) when real storage is needed for other purposes.
- I/O Requirement: Writing a dirty page back to auxiliary storage incurs an I/O operation, which can impact system performance.
- Data Integrity: The process of writing dirty pages ensures that changes made by applications or the system are persistently saved.

Use Cases

- Database Updates: When a transaction modifies data in a DB2 buffer pool or an IMS data space, the corresponding 4KB pages in real storage become dirty and must eventually be written to disk.
- File System Writes: Modifying a VSAM dataset or a zFS file can result in dirty pages in the relevant data buffers or caches, which are then flushed to auxiliary storage.
- Application Working Storage: If an application's working storage is backed by auxiliary storage and modified, those pages become dirty.
- System Control Blocks: Updates to system control blocks or tables that are backed by auxiliary storage will generate dirty pages.

Related Concepts

Dirty pages are fundamental to virtual storage management in z/OS. They are managed by the Virtual Storage Manager (VSM) and the Auxiliary Storage Manager (ASM). When z/OS needs to reclaim real storage, it prioritizes paging out "clean" pages (unmodified) first, but if real storage pressure is high, dirty pages must also be written out to page datasets on auxiliary storage. This process is known as paging or swapping, and it directly impacts the system's working set and overall performance.

Best Practices:

Monitor Paging Rates: Regularly monitor the number of dirty pages written to auxiliary storage (page-outs) using tools like RMF to identify potential real storage constraints or inefficient application behavior.
Optimize Buffer Pools: Configure database (DB2, IMS) and file system (VSAM, zFS) buffer pools effectively to minimize unnecessary page-outs and reduce I/O overhead.
Efficient Application Design: Design applications to minimize modifications to data that frequently resides in virtual storage, thereby reducing the number of dirty pages generated.
Adequate Auxiliary Storage: Ensure that page datasets are sized appropriately and reside on fast I/O devices to handle dirty page writes efficiently.
Understand Write-Behind Caching: Recognize that dirty pages are a form of write-behind caching, where writes are deferred to improve application response times, but eventually incur I/O.