Global cache performance metrics are not correctly measured. It is not understood clearly either. There are even few blogs and web pages disseminating incorrect information. This blog entry is an attempt to offer few methods and scripts to understand global cache performance.
Always review all instances
It is very important to review the performance metrics from all instances in that RAC cluster, not just one instance that you are connected. If you have access to AWR reports, then it is critical to generate AWR reports (or statspack reports) from all instances. But, the problem is that, DBAs tend to generate AWR reports after logging in to each instance iteratively, enter couple of parameters and then reports are generated. Not exactly a convenient practice.
REM connect to each instance separately, type in the beginning snap_id and ending snap_id for each node etc.. sqlplus mydba@proddb1 @$ORACLE_HOME/rdbms/admin/awrrpt.sql exit; sqlplus mydba@proddb2 @$ORACLE_HOME/rdbms/admin/awrrpt.sql exit; sqlplus mydba@proddb3 @$ORACLE_HOME/rdbms/admin/awrrpt.sql exit;
There are few issues with this approach. It is a cumbersome practice if the instance count is higher. In addition to that, all of AWR reports are, in turn, accessing underlying AWR tables. Physically, rows from all instances are together in the same block and so, by executing these reports connecting to various instances, Global cache traffic is increased. If the database is suffering from Global cache (GC) performance issues then generating reports connecting to various instances is probably not a grand idea.
I have created few basic scripts to generate AWR reports from all instances in a single step. Script awrrpt_all_gen.sql queries AWR tables and gv$instance to access last snap_id and various instance_ids. Then this script generates AWR reports for all instances in that cluster in the current directory, for the last AWR snap. This script is quite handy while debugging RAC performance issues. Now, we have AWR reports from all instances in one directory and we can easily grep these files to understand metrics in various instances.
@awrrpt_all_gen.sql awrrpt_all_gen.sql v1.00 by Riyaj Shamsudeen @orainternals.com To generate AWR Report from all RAC instances concurrently. Creates reports using last two snap_ids. ...Generating awrrpt_all.sql script.... Please wait.... ...Completed script generation. Executing awrrpt_all.sql to generate AWR reports. ...Generates AWR reports with file name format awrrpt___.txt for each instance. ...Please wait for few minutes... ...AWR report created for instance 1. Please wait.. ...AWR report created for instance 2. Please wait.. ...AWR report created for instance 3. Please wait.. ...AWR report created for instance 4. Please wait.. AWR reports created.
If you would like ability to choose the snap_ids, then use the script awrrpt_all_range_gen.sql
Use granular approach to GC measurements
It is important to measure Global cache performance metrics correctly, especially those damned averages. Incorrect measurements of averages can lead to faulty analysis. For example, following query is retrieving average global cache CR receive time from gv$sysstat view. Problem with this SQL statement is that this statement is retrieving average global cache receive time from the restart of the instances. Global cache performance is quite sensitive to workload and querying over a wide time range, as in this query, can lead to faulty analysis.
REM This is really a bad idea!! select b1.inst_id, b2.value "RECEIVED", b1.value "RECEIVE TIME", ((b1.value / b2.value) * 10) "AVG RECEIVE TIME (ms)" from gv$sysstat b1, gv$sysstat b2 where b1.name = 'gc current block receive time' and b2.name = 'gc current blocks received' and b1.inst_id = b2.inst_id;
As an analogy, above query is equivalent to a patient-Doctor conversation:
Patient: Doctor, I don’t feel good. I feel that I am having fever.
Doctor : Nope. Your average body temperature from the beginning of this year is around 98. So, you are doing excellent.
It is essential to review the global cache performance metrics at a granular level. Use AWR reports or statspack reports for a short period of time. Better yet, if you want to quickly review GC performance metrics, you can use my script gc_traffic_print.sql. This script captures various statistics relevant to Global cache performance in to a PL/SQL table, sleeps for N seconds (default N=60) and re-captures the statistics after the sleep. Then the script prints all the relevant details in easily readable tabular format. Very useful in quickly reviewing the Global cache performance metrics.
SQL>@gc_traffic_print.sql gc_traffic_print.sql v1.20 by Riyaj Shamsudeen @orainternals.com ...Calculating GC Rx and Tx timing and blocks.. ...Default collection period is 60 seconds.... Please wait for at least 60 seconds... Enter value for sleep: 30 ---------|--------------|---------|----------------|----------|---------------|---------------|-------------| Inst | CR blocks Rx | CR time | CUR blocks Rx | CUR time | CR blocks Tx | CUR blocks Tx |Tot blocks | ---------|--------------|---------|----------------|----------|---------------|---------------|-------------| 1 | 29288| 12.17| 14914| 4.58| 27059| 17439| 88700| 2 | 21201| 5.75| 12835| 5.19| 26831| 16741| 77608| 3 | 22942| 4.64| 11751| 3.82| 23918| 9205| 67816| 4 | 32075| 4.78| 19260| 4.55| 31046| 19331| 101712| ---------|--------------|---------|----------------|----------|---------------|---------------|-------------| PL/SQL procedure successfully completed.
Column key for the above script is:
CR block RX : GC CR blocks received
CR time : Average GC CR receive time
CUR blocks RX: GC CUR blocks received
CUR time: Average GC CuR receive time
CR blocks TX: GC CR blocks transmitted
CUR blocks TX: GC CUR blocks transmitted
tot blocks: Sum of transmitted + received for both CR and CUR traffic
Breakup: global cache performance
Global cache processing performance can be broken down to its sub components ( excluding wire latency, but that can be calculated). Breakup of this metrics must be done at a granular level also. We can use yet another script gc_traffic_processing.sql to review the performance metrics for the past N seconds. For example, in the output printed below, Global cache CR processing time is broken in to various sub-components of global cache processing. Remember that these performance metrics are in the SEND side of Global cache performance metrics. Meaning, inefficient global cache processing in one instance affects other instances' global cache receive time, but not the self. For example, in the table above, GC CR receive performance was at 12.1ms for instance 1. That is due to another instance (probably node 4 in this case) suffering from high GC processing time (more specifically high 'CR block flush time' in node 4). It is far more accurate to review global cache performance issues in a granular basis. Caution though, try not to specify at least a minute so that these numbers are consistent.
@gc_traffic_procssing.sql gc_traffic_processing.sql v1.00 by Riyaj Shamsudeen @orainternals.com ...Prints various timing related information for the past N seconds ...Default collection period is 60 seconds.... Please wait for at least 60 seconds... Enter value for sleep: ---------|-----------|---------|-----------|----------|------------|------------|------------|----------| Inst | CR blk Tx | CR bld | CR fls tm | CR snd tm| CUR blk TX | CUR pin tm | CUR fls tm |CUR snd tm| ---------|-----------|---------|-----------|----------|------------|------------|------------|----------| 1 | 62732| .2| 1.25| .21| 48920| .96| .22| .22| 2 | 46037| .13| .76| .2| 42019| .68| .17| .2| 3 | 72237| .63| .79| .19| 22697| .44| .29| .23| 4 | 113816| .13| 2.04| .15| 51020| .87| .12| .13| -------------------------------------------------------------------------------------------------------- PL/SQL procedure successfully completed.
Here is the column definitions for the script output:
CR blk TX: GC CR blocks served
CR bld : Average GC CR build time/CR block served
CR fls tm: Average GC CR flush time/CR block served
CR snd tm: Average GC CR send time/CR block served
CUR blk TX: GC CUR blocks served
CUR pin tm: Average GC Current pin time /CUR block served
CUR fls tm : Average GC Current flush time/CUR block served
CUR snd tm: Average GC current send time/CUR block served
Review histograms for GC events
Averages can be misleading. Revealing performance issues underneath the average is a very important task to do. For example, we see that 'gc cr block receive time' average is high. But, let's review the histogram for the gc events related to Global cache receive time. My script gc_event_histogram.sql is quite handy to review event histograms. This script provides a difference in performance statistics between two samples and prints them in a readable format. In this case, node 1 is has 8578 waits for the event 'gc cr block 2-way' under 2ms and the sessions in instance 1 had 9851 waits between 2-4ms. Only few waits over 16ms.
@gc_event_histogram.sql gc_event_histogram.sql v1.0 by Riyaj Shamsudeen @orainternals.com Default collection period is sleep seconds. Please wait.. Enter value for event: gc cr block 2-way Enter value for sleep: 60 ---------|-----------------------|----------------|----------| Inst id | Event |wait time milli |wait cnt | ---------|-----------------------|----------------|----------| 1 |gc cr block 2-way | 1| 98| 1 |gc cr block 2-way | 2| 8578| 1 |gc cr block 2-way | 4| 9851| 1 |gc cr block 2-way | 8| 2291| 1 |gc cr block 2-way | 16| 117| 1 |gc cr block 2-way | 32| 6| 1 |gc cr block 2-way | 64| 1| 1 |gc cr block 2-way | 128| 2| 1 |gc cr block 2-way | 256| 0| 1 |gc cr block 2-way | 512| 0| 1 |gc cr block 2-way | 1024| 0| 1 |gc cr block 2-way | 2048| 0| 1 |gc cr block 2-way | 4096| 0| 1 |gc cr block 2-way | 8192| 0| 1 |gc cr block 2-way | 16384| 0| 2 |gc cr block 2-way | 1| 155| 2 |gc cr block 2-way | 2| 10792| 2 |gc cr block 2-way | 4| 14201| 2 |gc cr block 2-way | 8| 3887| 2 |gc cr block 2-way | 16| 204| ...
But, we also need to see 3-way waits. Let's review 3-way waits with the above script. We will simply supply 'gc cr block 3-way' as the wait event. In this case, we see that there are 12,062 waits over between 4-8ms. Of course, this must be improved.
@gc_event_histogram.sql gc_event_histogram.sql v1.0 by Riyaj Shamsudeen @orainternals.com Default collection period is sleep seconds. Please wait.. Enter value for event: gc cr block 3-way Enter value for sleep: 60 ---------|-----------------------|----------------|----------| Inst id | Event |wait time milli |wait cnt | ---------|-----------------------|----------------|----------| 1 |gc cr block 3-way | 1| 3| 1 |gc cr block 3-way | 2| 320| 1 |gc cr block 3-way | 4| 17017| 1 |gc cr block 3-way | 8| 12062| 1 |gc cr block 3-way | 16| 1725| 1 |gc cr block 3-way | 32| 113| 1 |gc cr block 3-way | 64| 0| 1 |gc cr block 3-way | 128| 0| 1 |gc cr block 3-way | 256| 0| 1 |gc cr block 3-way | 512| 0| 1 |gc cr block 3-way | 1024| 0| 1 |gc cr block 3-way | 2048| 0| 1 |gc cr block 3-way | 4096| 0| 1 |gc cr block 3-way | 8192| 0| ...
In essence, these four scripts will be useful in debugging Global cache performance issues. Please let me know if you encounter errors in these scripts. We will use these scripts in future discussions to show how we resolved few RAC performance issues.
Image may be NSFW.
Clik here to view.
Clik here to view.
Clik here to view.
Clik here to view.
Clik here to view.
Clik here to view.
Clik here to view.
Clik here to view.