File systme caching has nothing to do with a database. It is an
operating system mechanism to improve I/O performance when working with
files. Operating systems attempt to improve I/O performance by caching
frequently used data (ie. a directory) in memory to avoid the physical
I/O delays when it's necessary to READ data. On a dedicated database
system, this acts in a similar fashion to a processor's level 1 and
level 2 caches where the buffer pool is level 1 and the file system
cache is level 2. (Note that the cache proportions here are much
different than hardware caches.)
Real memory larger than program needs, if not used, is a wasted
resource. Mature, well designed, operating systems such as AIX, UNIX,
LINUX and others use this "excess" memory to support a large file system
cache. When program memory requirements rise, then the cache is shrunk
as needed. As requirements fall, the cache is expanded keeping memory
"in use".
Vmstat only provides you with part of the information you need to
determine if your database system is taking advantage of the operating
system's file caching mechanism. You need database statistics showing
the percentage of requests being handled by the buffer pool and the I/O
performance when the data being read is not in the buffer pool. Don't
forget that UDB uses two I/O mechansims, one for individual rows,
another for scans. Descriptions of the statistics and the formulas to
compute I/O performance are available in the manuals.
Your vmstat output indicates 2g memory on the system with about 35% of
it currently being used for caching the file system. If this system is
only a database servier, then your "big enough" buffer pool could be
expanded quite a bit. A competent DBA, with a good knowledge of the
application requirements can probably find a better use for the memory
than the file system's caching mechanism can.
I'd get a good baseline of buffer pool performance under a number of
different workloads and start altering your tablespaces, one by one, to
not use file system caching. Carefully measure buffer pool performance
with each one you change to verify that you are maintaining your buffer
pool performance. Don't be surprised if you see little change in the
vmstat file pages because the operating system will fill them with other
file data. Also keep an eye on paging - it it starts rising, you'll need
to investigate its causes.
Philip Sherman
Raj wrote:
What is the purpose of file system caching while creating a tablespace?
Memory on the test server gets used up pretty quickly after a user
executes a complex query(database is already activated), after some
investgation i found out that most of it being consumed by filesystem
caching... thanks to Liam and Phil Sherman for their valuable
suggestions. Is it safe to turn off filesystem caching on every
tablespaceon the server(i.e. DIO) ?? or can we set DB2_MMPAP_READ=ON
and DB2_MMAP_WRITE=ON ?? what is the down side of it?? We do have a big
enough bufferpool...
---------------------------------------------------------------------------------------------------------------------------------------
vmstat -v
2097152 memory pages
1982466 lruable pages
862 free pages
1 memory pools
130485 pinned pages
80.1 maxpin percentage
20.0 minperm percentage
80.0 maxperm percentage
37.7 numperm percentage
747627 file pages
0.0 compressed percentage
0 compressed pages
0.0 numclient percentage
80.0 maxclient percentage
0 client pages
0 remote pageouts scheduled
0 pending disk I/Os blocked with no pbuf
1199107 paging space I/Os blocked with no psbuf
1744312 filesystem I/Os blocked with no fsbuf
0 client filesystem I/Os blocked with no fsbuf
0 external pager filesystem I/Os blocked with no
fsbuf
---------------------------------------------------------------------------------------------------------------------------------------
Thanks,
Raj
