By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
437,924 Members | 1,727 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 437,924 IT Pros & Developers. It's quick & easy.

db2 File system caching ..DIO or CIO??

P: n/a
Raj
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

Mar 31 '06 #1
Share this Question
Share on Google+
5 Replies


P: n/a
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

Mar 31 '06 #2

P: n/a
Raj
Thank you so much for your time and the detailed explanation ...The mem
allocation on our server is --> out of 8gb mem, 2.7 gb is allocated
to bufferpools and 4.2G is used by db2, when we run complex sql's the
free memory (from nmon/vmstat) reduces and paging happens (pi & po
vmstat )...

Mar 31 '06 #3

P: n/a
Ian

The only point I would add to Phil's comments: The file system cache
effectively creates double-buffering if you are using SMS or DMS file
containers. This degrades performance somewhat, and is why solutions
like concurrent IO or direct IO are helpful in database systems.

Also: On AIX (since that's what you show in vmstat -v output), you
can alter the behavior of the file system cache with the vmo command
and the minperm/maxperm parameters.
Apr 2 '06 #4

P: n/a
"Ian" <ia*****@mobileaudio.com> wrote in message
news:44********@newsfeed.slurp.net...

The only point I would add to Phil's comments: The file system cache
effectively creates double-buffering if you are using SMS or DMS file
containers. This degrades performance somewhat, and is why solutions
like concurrent IO or direct IO are helpful in database systems.

Also: On AIX (since that's what you show in vmstat -v output), you
can alter the behavior of the file system cache with the vmo command
and the minperm/maxperm parameters.


What about caching and pre-fetching built into some disk subsystems like
NAS?
Apr 2 '06 #5

P: n/a
Ian
Mark A wrote:
"Ian" <ia*****@mobileaudio.com> wrote in message
news:44********@newsfeed.slurp.net...
The only point I would add to Phil's comments: The file system cache
effectively creates double-buffering if you are using SMS or DMS file
containers. This degrades performance somewhat, and is why solutions
like concurrent IO or direct IO are helpful in database systems.

Also: On AIX (since that's what you show in vmstat -v output), you
can alter the behavior of the file system cache with the vmo command
and the minperm/maxperm parameters.


What about caching and pre-fetching built into some disk subsystems like
NAS?


What about them?

Caches at the disk subsystem level are a totally different beast from
the OS file system cache. Their effectiveness depends on a large number
of variables, such as workload (for the entire disk subsystem, not just
for the specific database), RAID and LUN design, and implementation at
both the OS and database levels.

Apr 2 '06 #6

This discussion thread is closed

Replies have been disabled for this discussion.