Browse oracle-l: This Month's Archive • Main Archive Page • Related posts • Previous by Date • Next by Date

RE: Metrics for Swingbench benchmarks

From: "John Hallas" <john.hallas@xxxxxxxxxx>
To: "Jeremy Schneider" <jeremy.schneider@xxxxxxxxxxxxxx>
Date: Fri, 14 Mar 2008 14:44:51 -0000

On all the RAC tests we have done  (and we really are pumping high
volumes through, in the order of thousands a second, where each
transaction is multiple table updates/insets) I see the following
overheads. These are general figures as throughput does vary and the
numbers are relative to us and would confuse the issue anyway

 

Standalone database, non RAC install   100%

RAC install single instance up  95%

RAC install dual instance, preferred and available, active/passive 90%

RAC install dual instance, preferred,preferred active/active 80%

 

Using Steams we see about another 10% hit (local capture)

 

The main misunderstanding I have is the difference between 95% and 90%.
The 2nd node is available but not in use. I know there will be heartbeat
and other maintenance work going on and I am also aware that the cache
fusion will keep the 2 SGAs in sync, however I have been searching for
more information on what is happening in the preffered/available modes
and any thoughts appreciated.

 

I am starting to put some of this stuff down in my newly formed blog at
www.jhdba.wordpress.com

 

________________________________

From: Jeremy Schneider [mailto:jeremy.schneider@xxxxxxxxxxxxxx] 
Sent: 14 March 2008 01:38
To: John Hallas
Cc: oracle-l@xxxxxxxxxxxxx
Subject: Re: Metrics for Swingbench benchmarks

 

 

On Mon, Mar 3, 2008 at 9:46 AM, John Hallas <john.hallas@xxxxxxxxxx>
wrote:

When we ran an insert stress test (again using the Order Entry schema)
we achieved 410000 TPM with a single load generator to a single
instance, 320000 when both instances were running and a pathetic 120000
when we added a second load generator.


So RAC with two nodes actually gave you slower performance than just a
single one of the nodes?

        Under every test we see the main problem being the major
contention on gc_buffer_busy blocks. 


That makes sense; anything to decrease that block contention could
increase your throughput.  Higher pctfree, partitioning if each node can
insert into its own partition...  (I assume you're using ASSM already to
avoid freelist pitfalls...)



-- 
Jeremy Schneider
Chicago, IL
http://www.ardentperf.com/category/technical




The information included in this email and any files transmitted with it may 
contain information that is confidential and it must not be used by, or its 
contents or attachments copied or disclosed, to persons other than the intended 
addressee. If you have received this email in error, please notify BJSS.
In the absence of written agreement to the contrary BJSS’ relevant standard 
terms of contract for any work to be undertaken will apply.
Please carry out virus or such other checks as you consider appropriate in 
respect of this email.  BJSS do not accept responsibility for any adverse 
effect upon your system or data in relation to this email or any files 
transmitted with it.
BJSS Limited, a company registered in England and Wales (Company Number 
2777575), VAT Registration Number 613295452, Registered Office Address, First 
Floor, Coronet House, Queen Street, Leeds, LS1 2TW

Follow-Ups:

Re: Metrics for Swingbench benchmarks
From: Jeremy Schneider

References:
- Metrics for Swingbench benchmarks
  - From: John Hallas
- Re: Metrics for Swingbench benchmarks
  - From: Jeremy Schneider

RE: Metrics for Swingbench benchmarks

Other related posts: