Oracle 11g Result Cache Tested on Eight-Way Itanium

Nov 27, 2007 / By Alex Fatkulin

Tags:

This will be the final post in my series on Result Caches. In my previous article, I had already got almost everything. Almost — four CPUs (cores) were still not enough to saturate the single latch. As you’ve probably already guessed, today we are going with an eight-way test.

Please note that today’s numbers are different since I’m using an entirely different hardware platform. While the four-way tests were done on a 2.4GHz Core 2 Quad box, today’s eight-way tests were done using four dual core Itanium 2 CPUs running at 1.1GHz.

Let’s take a look at the results:

# of processesBuffer Cache% linearResult Cache% linear

1 15085 100% 15451 100%
2 26745 88.65% 28881 93.46%
3 39144 86.5% 40628 87.65%
4 52342 86.75% 52625 85.15%
5 63922 84.75% 62767 81.25%
6 76336 84.34% 69549 75.02%
7 88844 84.14% 74208 68.61%
8 100959 83.66% 76768 62.11%

I made a nice-looking graph from this:

BC vs. RC

The performance drops are quite dramatic. While going from one to two processes can bring us an additional 13430 RC lookups per second, going from seven to eight processes gives us only 2560.

And stats regarding Result Cache: Latch:

# of processesGetsMissesSleepsWait Time

1 2000001 0 0 0
2 4000002 10004 12 5137
3 6000003 198365 7338 93164
4 8000004 473303 37683 330768
5 10000005 997602 131166 1165493
6 12000006 1838640 345487 3652257
7 14000007 3059147 756540 9915421
8 16000008 4579892 1436130 24922732

Here’s another pretty graph, this time of Result Cache: Latch wait time:

RC Latch Wait

As you can see from the above figures, it only takes six concurrently-running processes before we start observing major issues regarding the Result Set: Latch contention.

4 Responses to “Oracle 11g Result Cache Tested on Eight-Way Itanium”

Leave a Reply

  • (will not be published)

XHTML: You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>