RE: Metrics for Swingbench benchmarks

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_at_ardentperf.com] Sent: 14 March 2008 01:38
To: John Hallas
Cc: oracle-l_at_freelists.org
Subject: Re: Metrics for Swingbench benchmarks    

On Mon, Mar 3, 2008 at 9:46 AM, John Hallas <john.hallas_at_bjss.co.uk> 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

--

http://www.freelists.org/webpage/oracle-l Received on Fri Mar 14 2008 - 09:44:51 CDT