Understanding Buffer Pool Performance and Tuning in DB2 UDB v8.1
Understanding Buffer Pool Performance and Tuning in DB2 UDB v8.1
Understanding Buffer Pool Performance and Tuning in DB2 UDB v8.1
Create successful ePaper yourself
Turn your PDF publications into a flip-book with our unique Google optimized e-Paper software.
<strong>Underst<strong>and</strong><strong>in</strong>g</strong> <strong>Buffer</strong> <strong>Pool</strong><br />
<strong>Performance</strong> <strong>and</strong> <strong>Tun<strong>in</strong>g</strong> <strong>in</strong><br />
<strong>DB2</strong> <strong>UDB</strong> <strong>v8.1</strong><br />
Josh Steffan & Scott Olson<br />
Product Management<br />
<strong>DB2</strong>-Solutions
Agenda<br />
� <strong>Buffer</strong> pool overview<br />
� <strong>Buffer</strong> pool management<br />
� Collect<strong>in</strong>g performance metrics<br />
� <strong>Buffer</strong> pool effectiveness criteria<br />
– Physical vs. logical IO<br />
– Asynchronous vs. synchronous IO<br />
– Page cleaner tun<strong>in</strong>g<br />
� <strong>Tun<strong>in</strong>g</strong> with Quest Central (live demo)<br />
� Open forum
Introduction<br />
� With so many tun<strong>in</strong>g areas to focus<br />
on why should we pay special<br />
attention to the buffer pool?<br />
� <strong>DB2</strong> uses the buffer pool to offset<br />
the performance disparity between<br />
CPU <strong>and</strong> disk, so they are vital for<br />
optimiz<strong>in</strong>g transaction throughput
You Are Here – <strong>DB2</strong> Process Model<br />
Listener<br />
Client<br />
Application<br />
Coord<strong>in</strong>ator<br />
Subagents<br />
Prefetchers<br />
<strong>Buffer</strong> <strong>Pool</strong><br />
Logger<br />
External<br />
Storage<br />
Page<br />
Cleaners<br />
Log
You Are Here – <strong>DB2</strong> Process Model<br />
Listener<br />
Client<br />
Application<br />
Coord<strong>in</strong>ator<br />
Subagents<br />
Prefetchers<br />
<strong>Buffer</strong> <strong>Pool</strong><br />
Logger<br />
External<br />
Storage<br />
Page<br />
Cleaners<br />
Log
Overview of <strong>DB2</strong> <strong>Buffer</strong> <strong>Pool</strong>s<br />
� A buffer pool is an area of memory <strong>in</strong>to<br />
which database pages are read, modified,<br />
<strong>and</strong> held dur<strong>in</strong>g process<strong>in</strong>g<br />
– A hit occurs when a page that the database manager<br />
needs is found <strong>in</strong> the buffer pool<br />
– A miss occurs when a needed page can’t be found <strong>in</strong><br />
the buffer pool<br />
� Pages <strong>in</strong> the buffer pool exist <strong>in</strong> one of<br />
three states: <strong>in</strong> use, dirty, or clean
Prefetch<strong>in</strong>g <strong>and</strong> Page Clean<strong>in</strong>g<br />
� Although buffer pools improve<br />
performance for pages <strong>in</strong> memory, the<br />
process of mov<strong>in</strong>g pages <strong>in</strong> <strong>and</strong> out of<br />
memory still requires a lot of IO<br />
� <strong>DB2</strong> uses prefetch <strong>and</strong> page cleaner<br />
processes to reduce the time that agents<br />
have to wait for IO operations to<br />
complete
Prefetchers<br />
� Prefetchers (db2pfchr) ensure that agents do<strong>in</strong>g<br />
scans never wait for disk IO<br />
� Agents send asynchronous read-ahead requests<br />
to a common prefetch queue<br />
� Prefetchers service the requests by br<strong>in</strong>g<strong>in</strong>g the<br />
requested pages <strong>in</strong>to the buffer pool<br />
� Prefetch<strong>in</strong>g occurs two ways:<br />
– List prefetch, efficiently reads a set of nonconsecutive<br />
data pages<br />
– Sequential prefetch, reads consecutive pages
Page Cleaners<br />
� Page cleaners (db2pclnr) ensure that<br />
agents try<strong>in</strong>g to br<strong>in</strong>g a page <strong>in</strong>to the<br />
buffer pool never need to flush a dirty page<br />
to disk to free up a slot<br />
� Configuration parameters<br />
– Number of page cleaners for a database<br />
(num_iocleaners)<br />
– Level (percentage) of changed pages at which the<br />
page cleaners will be started, if they are not<br />
currently active (chngpgs_thresh)
You Are Here – <strong>DB2</strong> Process Model<br />
Listener<br />
Client<br />
Application<br />
Coord<strong>in</strong>ator<br />
Subagents<br />
Prefetchers<br />
<strong>Buffer</strong> <strong>Pool</strong><br />
Logger<br />
External<br />
Storage<br />
Page<br />
Cleaners<br />
Log
Non-<strong>Buffer</strong>ed IO<br />
� The buffer pool is not ideal for all types of IO<br />
� Large object data types such as LONG VARCHAR,<br />
BLOB <strong>and</strong> CLOB are retrieved directly from disk<br />
us<strong>in</strong>g non-buffered (direct) IO<br />
� Keep<strong>in</strong>g large object pages out of the buffer pool<br />
helps <strong>DB2</strong> ma<strong>in</strong>ta<strong>in</strong> effective cach<strong>in</strong>g for small<br />
data types<br />
1 GB BLOB 1 GB BP Disk<br />
Without direct IO,<br />
large data types would<br />
force <strong>DB2</strong> to flush all<br />
resident pages to disk<br />
– ru<strong>in</strong><strong>in</strong>g the hit rate
<strong>Buffer</strong> <strong>Pool</strong> Management<br />
� The IBMDEFAULTBP is automatically created with<br />
each database with additional buffer pools added<br />
with the CREATE BUFFERPOOL statement<br />
� SYSCTRL or SYSADM privileges are required to<br />
work with buffer pools<br />
CREATE BUFFERPOOL bufferpool_name SIZE number of pages<br />
[IMMEDIATE | DEFERRED]<br />
[PAGESIZE <strong>in</strong>teger [K]]<br />
[[NOT] EXTENDED STORAGE<br />
| NUMBLOCKPAGES number of pages [BLOCKSIZE number of pages]]<br />
[ALL DBPARTITIONNUMS<br />
| DATABASE PARTITION GROUP db_partition_group_name [,…]]<br />
[EXCEPT ON DBPARTITIONNUM[S] (db_partition_number1 [TO db_partition_number2]<br />
SIZE number of pages [,…])]
<strong>Buffer</strong> <strong>Pool</strong> Management<br />
� <strong>DB2</strong> requires 100 bytes of memory for every<br />
buffer pool <strong>and</strong> extended storage page that is<br />
allocated to a database for use as a descriptor <strong>in</strong><br />
the database heap (DBHEAP)<br />
CREATE BUFFERPOOL bufferpool_name SIZE number of pages<br />
[IMMEDIATE | DEFERRED]<br />
[PAGESIZE <strong>in</strong>teger [K]]<br />
[[NOT] EXTENDED STORAGE<br />
| NUMBLOCKPAGES number of pages [BLOCKSIZE number of pages]]<br />
[ALL DBPARTITIONNUMS<br />
| DATABASE PARTITION GROUP db_partition_group_name [,…]]<br />
[EXCEPT ON DBPARTITIONNUM[S] (db_partition_number1 [TO db_partition_number2]<br />
SIZE number of pages [,…])]
Extended Storage<br />
� 32-bit <strong>DB2</strong> can’t support creat<strong>in</strong>g buffer pools larger than<br />
4 gigabytes due to addressable storage limits<br />
� Extended storage allows <strong>DB2</strong> to flush pages to memory<br />
rather than disk, so future access to the pages is much<br />
faster<br />
� Before extended storage can be used, the<br />
NUM_ESTORE_SEGS <strong>and</strong> ESTORE_SEG_SIZE database<br />
configuration parameters must be set<br />
CREATE BUFFERPOOL bufferpool_name SIZE number of pages<br />
[IMMEDIATE | DEFERRED]<br />
[PAGESIZE <strong>in</strong>teger [K]]<br />
[[NOT] EXTENDED STORAGE<br />
| NUMBLOCKPAGES number of pages [BLOCKSIZE number of pages]]<br />
[ALL DBPARTITIONNUMS<br />
| DATABASE PARTITION GROUP db_partition_group_name [,…]]<br />
[EXCEPT ON DBPARTITIONNUM[S] (db_partition_number1 [TO db_partition_number2]<br />
SIZE number of pages [,…])]
Block-Based <strong>Buffer</strong> <strong>Pool</strong>s<br />
� Applications that employ sequential prefetch<strong>in</strong>g can benefit<br />
from improved performance through the use of blockbased<br />
buffer pools, which allow blocks of contiguous pages<br />
to be moved <strong>in</strong>to contiguous portions of memory<br />
� Keep <strong>in</strong> m<strong>in</strong>d that block-based pages will be wasted if your<br />
application doesn’t perform sequential prefetch<strong>in</strong>g<br />
CREATE BUFFERPOOL bufferpool_name SIZE number of pages<br />
[IMMEDIATE | DEFERRED]<br />
[PAGESIZE <strong>in</strong>teger [K]]<br />
[[NOT] EXTENDED STORAGE<br />
| NUMBLOCKPAGES number of pages [BLOCKSIZE number of pages]]<br />
[ALL DBPARTITIONNUMS<br />
| DATABASE PARTITION GROUP db_partition_group_name [,…]]<br />
[EXCEPT ON DBPARTITIONNUM[S] (db_partition_number1 [TO db_partition_number2]<br />
SIZE number of pages [,…])]
Hidden <strong>Buffer</strong> <strong>Pool</strong>s<br />
� To improve availability, <strong>DB2</strong> creates small (16<br />
page) buffer pools of each page size 4, 8, 16 <strong>and</strong><br />
32 kilobytes at database activation<br />
� These buffer pools are hidden from the user <strong>and</strong><br />
are only used when ord<strong>in</strong>ary buffer pools cannot<br />
be allocated<br />
� If used, performance will be noticeably impacted<br />
<strong>and</strong> <strong>DB2</strong> will write a warn<strong>in</strong>g message to the<br />
adm<strong>in</strong>istration notification log
Related Objects<br />
� The table space create statement specifies a<br />
buffer pool to use, so it is the table space <strong>and</strong><br />
not the table that determ<strong>in</strong>es <strong>in</strong> which buffer<br />
pool the pages will be cached<br />
� buffer pool <strong>and</strong> table space page sizes must<br />
match – valid values are 4, 8, 16, <strong>and</strong> 32<br />
kilobytes<br />
� Database partition group are also related to<br />
buffer pools, s<strong>in</strong>ce a partition group can be<br />
specified <strong>in</strong> the CREATE BUFFERPOOL statement<br />
to control upon which partitions a given buffer<br />
poll is created
<strong>Buffer</strong> <strong>Pool</strong> <strong>Tun<strong>in</strong>g</strong> Methodology<br />
� Collect the performance data<br />
– Snapshot monitor<strong>in</strong>g<br />
– Event monitor<strong>in</strong>g<br />
� Review the results (Know what to look for?)<br />
– Underst<strong>and</strong> SQL workload<br />
– Evaluate performance (calculations)<br />
� Take action (examples)<br />
– Resize buffer pools<br />
– Def<strong>in</strong>e more page cleaners<br />
– Break out tables with “like” workloads<br />
� Start the process aga<strong>in</strong>
Collect<strong>in</strong>g <strong>Performance</strong> Data<br />
Snapshot monitor<br />
“Po<strong>in</strong>t <strong>in</strong> time” representation of data<br />
Less overhead (~5%)<br />
Need to reissue over time<br />
Monitor Switches need to be turned<br />
on at the <strong>in</strong>stance level to collect<br />
data<br />
“Real time” balance of application <strong>and</strong><br />
database performance<br />
Event Monitor<br />
“Event” based representation of data<br />
More overhead (~10-20%)<br />
“Create” it once <strong>and</strong> it runs until it’s<br />
told to stop.<br />
“Create” takes care of everyth<strong>in</strong>g<br />
“Historical” ma<strong>in</strong> focus on Application<br />
statistics
<strong>DB2</strong> Snapshot Monitor<br />
� Seven Switches<br />
– <strong>Buffer</strong> <strong>Pool</strong> (dft_mon_bufpool)<br />
– Lock (dft_mon_lock)<br />
– Sort (dft_mon_sort)<br />
– Statement (dft_mon_stmt)<br />
– Unit of Work (dft_mon_uow)<br />
– Table (dft_mon_table)<br />
– Timestamp (dft_mon_timestamp)
<strong>DB2</strong> Snapshot Monitor<br />
� Turn<strong>in</strong>g switches on at the <strong>in</strong>stance<br />
UPDATE DATABASE MANAGER CONFIGURATION USING<br />
dft_mon_bufpool ON<br />
dft_mon_lock ON<br />
dft_mon_sort ON<br />
dft_mon_stmt ON<br />
dft_mon_table ON<br />
dft_mon_uow ON<br />
IMMEDIATE<br />
� Turn<strong>in</strong>g switches on for session<br />
UPDATE MONITOR SWITCHES USING bufferpool ON
<strong>DB2</strong> Snapshot Monitor<br />
� Issu<strong>in</strong>g a request<br />
– Instance level (requires “ATTACH”)<br />
• For all active databases<br />
GET SNAPSHOT FOR ALL BUFFERPOOLS<br />
• For a specific database<br />
GET SNAPSHOT FOR BUFFERPOOLS ON database_name<br />
• For a specific database partition<br />
GET SNAPSHOT FOR BUFFERPOOLS ON database_name<br />
AT DBPARTITIONNUM db_partition_number<br />
� BUFFERPOOL <strong>and</strong> DATABASE snapshot calls are<br />
essential for tun<strong>in</strong>g buffer pools.
<strong>DB2</strong> Snapshot Output<br />
� BUFFERPOOL Snapshot<br />
<strong>Buffer</strong>pool name = BASEBP1<br />
Database name = BASEBALL<br />
Database path =<br />
C:\<strong>DB2</strong>\NODE0000\SQL00005\<br />
Input database alias = BASEBALL<br />
<strong>Buffer</strong> pool data logical reads = 300<br />
<strong>Buffer</strong> pool data physical reads = 3490<br />
<strong>Buffer</strong> pool data writes = 3050<br />
<strong>Buffer</strong> pool <strong>in</strong>dex logical reads = 67<br />
<strong>Buffer</strong> pool <strong>in</strong>dex physical reads = 34<br />
.<br />
.<br />
.<br />
Node number = 0<br />
Tablespaces us<strong>in</strong>g bufferpool = 4<br />
Alter bufferpool <strong>in</strong>formation:<br />
Pages left to remove = 0<br />
Current size = 1000<br />
Post-alter size = 1000
<strong>DB2</strong> Snapshot Output<br />
� DATABASE Snapshot<br />
Database name = AUTO_PRD<br />
Database path = C:\<strong>DB2</strong>\NODE0000\SQL00009\<br />
.<br />
.<br />
.<br />
<strong>Buffer</strong> pool data logical reads = 165079<br />
<strong>Buffer</strong> pool data physical reads = 36264<br />
Asynchronous pool data page reads = 10546<br />
<strong>Buffer</strong> pool data writes = 3991<br />
Asynchronous pool data page writes = 3873<br />
<strong>Buffer</strong> pool <strong>in</strong>dex logical reads = 4014<br />
<strong>Buffer</strong> pool <strong>in</strong>dex physical reads = 558<br />
Asynchronous pool <strong>in</strong>dex page reads = 332<br />
<strong>Buffer</strong> pool <strong>in</strong>dex writes = 26<br />
Asynchronous pool <strong>in</strong>dex page writes = 26<br />
Total buffer pool read time (ms) = 8329<br />
Total buffer pool write time (ms) = 121852<br />
Total elapsed asynchronous read time = 5353<br />
Total elapsed asynchronous write time = 121292<br />
Asynchronous read requests = 1681<br />
LSN Gap cleaner triggers = 24<br />
Dirty page steal cleaner triggers = 63<br />
Dirty page threshold cleaner triggers = 33<br />
Time waited for prefetch (ms) = 626
Evaluat<strong>in</strong>g <strong>Performance</strong><br />
� Know your workload<br />
– Is the SQL workload predom<strong>in</strong>antly…<br />
• Update, <strong>in</strong>sert, delete focused<br />
–Example<br />
»OLTP<br />
• Select focused<br />
–Examples<br />
»Ad hoc<br />
» Data warehouse<br />
– Event monitor<strong>in</strong>g can help if you are unsure
Evaluat<strong>in</strong>g <strong>Performance</strong><br />
Evaluat<strong>in</strong>g logical IO vs. physical IO:<br />
– M<strong>in</strong>imize the number of times <strong>DB2</strong> needs to access<br />
physical memory<br />
Approach:<br />
– Overall hit rate<br />
– Data hit rate<br />
– Index hit rate<br />
– Physical IO read rate
Logical vs. Physical IO<br />
� Overall Hit Rate<br />
– Includes ALL data <strong>and</strong> <strong>in</strong>dex reads by buffer pool<br />
⎡<br />
⎤<br />
⎢<br />
⎥<br />
( . . . . . . )<br />
Buffe<strong>Pool</strong>OHR<br />
⎢ bp datalogical<br />
reads+<br />
bp <strong>in</strong>dexlogical<br />
reads<br />
<strong>Buffer</strong>poolOHR<br />
=<br />
⎥*<br />
100<br />
⎢⎛bp.<br />
<strong>in</strong>dex.<br />
logical.<br />
reads+<br />
bp.<br />
<strong>in</strong>dex.<br />
physical.<br />
reads+<br />
⎞⎥<br />
⎢⎜<br />
⎟⎥<br />
⎣⎝bp.<br />
data.<br />
logical.<br />
reads+<br />
bp.<br />
data.<br />
physical.<br />
reads ⎠⎦<br />
� Low values = more physical IO<br />
� High values = more logical IO<br />
� 85 – 90% is a good start<strong>in</strong>g po<strong>in</strong>t
Logical vs. Physical IO<br />
� Data Hit Rate<br />
– Includes ALL data reads by buffer pool<br />
<strong>Buffer</strong>pool<br />
DHR<br />
=<br />
⎛<br />
⎜<br />
⎝<br />
bp.<br />
data.<br />
logical . reads<br />
bp.<br />
data.<br />
logical . reads + bp.<br />
data.<br />
physical . reads<br />
� Low values = more physical IO<br />
� High values = more logical IO<br />
� 85 – 90% is a good start<strong>in</strong>g po<strong>in</strong>t<br />
⎞<br />
⎟*<br />
100<br />
⎠
Logical vs. Physical IO<br />
� Index Hit Rate<br />
– Includes ALL <strong>in</strong>dex reads by buffer pool<br />
<strong>Buffer</strong>pool<br />
IHR<br />
=<br />
⎛<br />
⎜<br />
⎝<br />
bp.<br />
<strong>in</strong>dex.<br />
logical . reads<br />
bp.<br />
<strong>in</strong>dex.<br />
logical . reads + bp.<br />
<strong>in</strong>dex.<br />
physical . reads<br />
� Low values = more physical IO<br />
� High values = more logical IO<br />
� 85 – 90% is a good start<strong>in</strong>g po<strong>in</strong>t<br />
⎞<br />
⎟ * 100<br />
⎠
Logical vs. Physical IO<br />
� Physical IO Read Rate<br />
– Total number of physical reads by buffer pool over<br />
time<br />
PhysicalIOReads<br />
=<br />
⎛ bufferpool.<br />
data.<br />
logical.<br />
reads + bufferpool.<br />
data.<br />
⎜<br />
⎝<br />
total.<br />
collection.<br />
time<br />
� Use the follow<strong>in</strong>g:<br />
GET SNAPSHOT FOR TABLESPACES ON database_name<br />
� Evaluated by tablespace/buffer pool<br />
� Could <strong>in</strong>dicate the need for…<br />
– Additional conta<strong>in</strong>ers<br />
– <strong>Buffer</strong> pool breakout<br />
physical.<br />
reads<br />
⎞<br />
⎟<br />
⎠
Evaluat<strong>in</strong>g <strong>Performance</strong><br />
Evaluat<strong>in</strong>g Prefetch <strong>Performance</strong>:<br />
– Asynchronous vs. synchronous<br />
Approach:<br />
– Evaluate prefetch ratio<br />
– Know the workload<br />
– Evaluate prefetcher configuration
Asynchronous vs. Synchronous<br />
� Prefetch Ratio<br />
– Evaluated by buffer pool<br />
PrefetchRatio<br />
=<br />
⎛<br />
⎜<br />
⎝<br />
async.pool.data.reads<br />
bp.logical.reads<br />
� Lower values = more synchronous<br />
� Higher values = more asynchronous<br />
� Are there enough def<strong>in</strong>ed?<br />
+<br />
+<br />
async.pool.<strong>in</strong>dex.reads<br />
bp.<strong>in</strong>dex.logical.reads<br />
⎞<br />
⎟*<br />
100<br />
⎠
Asynchronous vs. Synchronous<br />
� Block IO<br />
– If sequential prefetch is happen<strong>in</strong>g?<br />
• Enable buffer pools to utilize block IO<br />
ALTER BUFFERPOOL basebp2 NUMBLOCKPAGES 30;<br />
ALTER BUFFERPOOL basebp2 BLOCKSIZE 10;<br />
– NUMBLOCKPAGES should be a multiple of<br />
block size
Evaluat<strong>in</strong>g <strong>Performance</strong><br />
Evaluat<strong>in</strong>g Page Cleaner <strong>Performance</strong>:<br />
– LSN Gap Triggers<br />
– Dirty Page Threshold Triggers<br />
– Dirty Page Steal Triggers<br />
Approach:<br />
– Evaluate each one aga<strong>in</strong>st all others<br />
– Modify parameters <strong>in</strong>fluenc<strong>in</strong>g page cleaner activity<br />
– Do you have enough page cleaners def<strong>in</strong>ed?
LCR<br />
Page Cleaner <strong>Performance</strong><br />
� Log Cleans Ratio<br />
⎛<br />
⎞<br />
⎜<br />
⎟<br />
⎜<br />
lsn.<br />
gap.<br />
cleaner.<br />
triggers<br />
⎟<br />
= ⎜<br />
* 100<br />
⎛ dirt.<br />
page.<br />
steal.<br />
cleaner.<br />
triggers + lsn.<br />
gap.<br />
cleaner.<br />
triggers ⎞<br />
⎟<br />
⎜<br />
⎟<br />
⎜<br />
⎜<br />
⎟<br />
. . . .<br />
⎟<br />
⎝ ⎝ + dirty page threshold cleaners triggers ⎠ ⎠<br />
� Has an affect on recovery times<br />
� Too small or too large could be detrimental to<br />
buffer pool performance<br />
� Affected by SOFTMAX DB CONFIG parameter
TCR<br />
Page Cleaner <strong>Performance</strong><br />
� Threshold Cleans Ratio (dirty pages)<br />
⎛<br />
⎞<br />
⎜<br />
⎟<br />
⎜ dirty.<br />
page.<br />
threshold . cleaner.<br />
triggers ⎟<br />
= ⎜<br />
* 100<br />
⎛ dirt.<br />
page.<br />
steal.<br />
cleaner.<br />
triggers + lsn.<br />
gap.<br />
cleaner.<br />
triggers ⎞<br />
⎟<br />
⎜<br />
⎟<br />
⎜<br />
⎜<br />
⎟<br />
. . . .<br />
⎟<br />
⎝ ⎝ + dirty page threshold cleaner triggers ⎠ ⎠<br />
� CHNGPGS_THRESH DB CONFIG parameter<br />
� The same 50% value has a different effect on<br />
small <strong>and</strong> large buffer pools<br />
� F<strong>in</strong>d<strong>in</strong>g a “happy” median is key
VCR<br />
Page Cleaner <strong>Performance</strong><br />
� Victim Cleans Ratio (dirty pages)<br />
⎛<br />
⎞<br />
⎜<br />
⎟<br />
⎜<br />
dirty.<br />
page.<br />
steal.<br />
cleaner.<br />
triggers<br />
⎟<br />
= ⎜<br />
* 100<br />
⎛ dirt.<br />
page.<br />
steal.<br />
cleaner.<br />
triggers + lsn.<br />
gap.<br />
cleaner.<br />
triggers ⎞<br />
⎟<br />
⎜<br />
⎟<br />
⎜<br />
⎜<br />
⎟<br />
. . . .<br />
⎟<br />
⎝ ⎝ + dirty page threshold cleaner triggers ⎠ ⎠<br />
� If above 40%, typically means buffer pool needs<br />
to be larger<br />
� Could also mean SOFTMAX parameter is too high<br />
(not enough page turnover)
Conclusion<br />
� Focus on three ma<strong>in</strong> areas…<br />
– BP hit ratios (logical vs. physical)<br />
– Prefetcher tun<strong>in</strong>g (asynchronous vs. synchronous)<br />
– Page cleaner tun<strong>in</strong>g<br />
� Collect the performance data over time<br />
– Sampl<strong>in</strong>g methodology<br />
• Sample snapshots every 5-15 m<strong>in</strong>utes over the course of the<br />
day or dur<strong>in</strong>g a batch run<br />
� Review the results (Know what to look for?)<br />
– Decipher data <strong>and</strong> plug <strong>in</strong>to equations<br />
– Know the workload<br />
– Chart performance over time<br />
� Take action<br />
– Various solutions depend<strong>in</strong>g on f<strong>in</strong>d<strong>in</strong>gs
Thank you