The User File (VM) Caching System Statistics report shows the performance
of the zFS user file cache. The Sysplex Client Caching System Statistics
Report shows the performance of the zFS client file cache. The size
of both of these caches is controlled by the IOEFSPRM user_cache_size or client_cache_size configuration
options or the zfsadm config command.
The zFS user file cache and the client file cache data are stored
in a collection of dataspaces. zFS prefers to use multiple dataspaces
rather than one large dataspace when it can to reduce lock contention
(as shown in this example). zFS has a structure for
each file that is cached. The client cache breaks the cached file
into 32 K segments and the user cache breaks the cached file into
64 K segments. In both cases, each segment is broken into 4 K
pages. A segment is assigned to a dataspace, hence the pages for any
given segment belong only to one dataspace. A file's pages can be
scattered throughout multiple segments.
At any given time, a file need not (and for large files often might
not) have all of its segments in the cache. Furthermore, any segment
need not (and often might not) have all of its pages in the cache.
Reuse of pages and segments is done in an least-recently used (LRU)
fashion.
The cache provides asynchronous read-ahead and write-behind of
large files when access is considered sequential. Read-ahead and write-behind
for a file is performed by reading/writing segments (up to 64 K).
Following is a sample VM report.
IOEZ00438I Starting Query Command VM.
User File (VM) Caching System Statistics
----------------------------------------
External Requests:
------------------
Reads 5107802 Fsyncs 1990 Schedules 366517
Writes 5503223 Setattrs 7091 Unmaps 349352
Asy Reads 3809619 Getattrs 1219759 Flushes 0
File System Reads:
------------------
Reads Faulted 164132 (Fault Ratio 3.213%)
Writes Faulted 167756 (Fault Ratio 3.048%
Read Waits 0 (Wait Ratio 0.000%)
Total Reads 357542
File System Writes:
-------------------
Scheduled Writes 119608 Sync Waits 22706
Error Writes 0 Error Waits 0
Scheduled deletes 0
Page Reclaim Writes 37315 Reclaim Waits 19392
Write Waits 5454 (Wait Ratio 0.099%
Page Management (Segment Size = 64K) ) (Page Size = 4K)
----------------------------------------------------
Total Pages 12800 Free 12800
Segments 2373
Steal Invocations 24146 Waits for Reclaim 62038
Number of dataspaces used: 1 Pages per dataspace: 12800
Dataspace Allocated Free
Name Segments Pages
-------- ---------- ----------
ZFSUCD00 0 12800
Sysplex Client Caching System Statistics
----------------------------------------
External Requests:
------------------
Reads 0 Fsyncs 0 Schedules 1
Writes 46737 Setattrs 0 Unmaps 0
Asy Reads 0 Getattrs 0 Flushes 0
File System Reads:
------------------
Reads Faulted 0 (Fault Ratio 0.000%)
Writes Faulted 0 (Fault Ratio 0.000%)
Read Waits 0 (Wait Ratio 0.000%)
Total Reads 0
File System Writes:
-------------------
Scheduled Writes 1462 Sync Waits 0
Error Writes 106 Error Waits 0
Scheduled deletes 0
Page Reclaim Writes 0 Reclaim Waits 0
Write Waits 0 (Wait Ratio 0.000%)
Page Management (Segment Size = 32K) ) (Page Size = 4K)
----------------------------------------------------
Total Pages 32768 Free 32263
Segments 16384
Steal Invocations 0 Waits for Reclaim 0
Number of dataspaces used: 2 Pages per dataspace: 16384
Dataspace Allocated Free
Name Segments Pages
-------- ---------- ----------
ZFSCCD00 96 15616
ZFSCCD01 96 15621
Table 1 describes the fields of the
User File (VM) Caching System Statistics report.
Table 1. User
File (VM) Caching System Statistics report fieldsField name |
Contents |
---|
External Requests: |
Describes the requests made to the user file
cache to perform operations as requested by applications. - Reads, Writes
- How often the cache was called to read or write files.
- Asy Reads
- How often read-ahead is performed.
- Fsync
- How often applications requested that zFS sync a file's data to
disk.
- Unmaps
- The count of file deletions.
|
File System Reads: |
Shows how often the cache reads data from disk
for a file. Cache misses and read I/Os degrade application response
time and the goal is for these numbers to be as low as possible. Increasing
the cache size is the typical method for lowering these numbers. - Reads Faulted
- Count of read requests that needed to perform at least one I/O
to read the requested portion of the file from disk.
- Writes Faulted
- Count of how often a write to a file needed to perform a read
from disk. If a write only updates a portion of a page of a file on
disk and that page is not in memory, then the page must be read in
(the zFS I/O driver can only perform I/O in whole pages) before the
new data is written to the in-memory page.
- Read Waits
- How often a read had to wait for a pending I/O. For example, how
often a read of a file found that the range of the file is pending
read (probably because of asynchronous read ahead).
- Total Reads
- Total number of file system reads made for any reason.
|
File System Writes: |
Shows how often the cache wrote the data to
disk. In general, it is desirable to minimize the Page Reclaim Writes
and Reclaim Waits. If these occur often, relative to the external
zFS request rate (shown in the KN report), then the cache might be
too small. - Scheduled Writes
- Count of how often the cache wrote out dirty segments for a file.
Segments are written as soon as every page becomes dirty (segments
are said to be dirty if they contain live blocks). When a file is
closed all of its dirty segments are scheduled asynchronously and
segments are also written asynchronously during file system syncs
through the zFS sync daemon (which by default runs every 30 seconds).
- Sync Waits
- Count of how often a fsync request that is needed to wait on pending
I/O for dirty segments.
- Error Writes and Error Waits
- Count of the error handling paths and should almost always be
0 unless a disk hardware error occurs. Whenever an unexpected error
occurs for a file, all of its dirty segments are written and synced
to disk. (A file system that is running out of space is not an error
condition that causes the cache to sync a file, the cache reserves
storage for files as they are written which ensures no unexpected
out of space conditions arise).
- Scheduled Deletes
- Count of times a pending I/O was canceled because a file was being
deleted. In this case, the data is not appropriate to be on disk (because
the file is 0 link count). Therefore, canceling the I/O is done to
avoid an I/O wait. This is a performance optimization for file remove.
- Page Reclaim Writes
- Count of times that a segment had to be written to DASD to reclaim
space in the cache
- Page Reclaim Waits
- Count of times that the reclaim function waited on pending I/O
to reclaim segment pages.
- Write Waits
- Count of times a write occurred to a page that was already pending
I/O. In this case, the I/O must be waited upon before the page is
updated with the new data.
|
Page Management: |
Shows how storage in the user file cache and
client file cache is used. It is generally desirable to minimize the
number of steal invocations (reclaims). This can typically be done
by increasing the size of the cache. Performance is increased as more
dataspaces are used.- Total pages
- The number of 4 K pages in the cache. That is, (user_cache_size /
4K) or (client_cache_size / 4K).
- Free
- The number of available 4 K pages in the cache.
- Segments
- The number of 64 K sections that was referenced in a file. The
number of segments starts out as half of vnode_cache_size and
is allocated as needed, similar to vnodes.
- Steal Invocations
- The number of times 4 K pages were reclaimed from the cache.
- Waits for Reclaim
- The number of times 4 K pages were reclaimed from the cache.
- Number of dataspaces
- The number of dataspaces used to hold the 4 K pages in the cache.
The pages are spread evenly across the dataspaces to allow for better
performance of the cache. The number of dataspaces used is approximately
one per 16384 4 K pages, up to a maximum of 32.
- Pages per dataspace
- The number of 4 K pages that is assigned to each dataspace.
|