[Info-ingres] Ingres/Replicator Stress Test
- From: martin.bowes@xxxxxxxxxxxxx
- Date: Wed, 23 Nov 2005 15:50:52 -0000
Hi Dudes,
I've been playing with Ingres/Replicator again - I think its good for my
stress levels, they weren't high enough.
So on my source database I have a single row table called next_id. It
holds a sequence counter. I'm going to replicate this to a target
database.
The table suffers from high concurrency, so I've altered its shadow and
archive tables to be hash with minpages 10240. This removed the
deadlocking problems.
So I wrote a test program to do inserts into another table using the
traditional 'get next id' procedure which updates the next_id table,
extracts the next_id and returns this to the caling program. It survives
small scale of 5inserts.
A simple stress test...Same program 5000 inserts.
Okay....
How come my target databases version of this table started with a
synched up single row and ended up with two rows, only one of which
had the correct final value of the next_id?
There were no deadlocks detected on the next_id, its shadow or
archive. There was a deadlock on the dd_distrib_queue which caused it
to fail on a delete.
There was only:
Server 2: test_u4::rep_src_mb server 2: Error -- Wed Nov 23 14:35:38 2005 -- 1
392 -- UPDATE collision found for table 'martinb.next_id',
Source DB 110, Transaction ID 1120740203, Sequence 1.
My CDDS is running with a 'Last Write Wins' Collision handling.
Can anyone start guessing what may have occurred to cause the
second row to appear.
Martin Bowes.
--
Random Duckman Quote #88:
Cornfed: For those of you who went out for a beer-- We've created a
monster.
.
- Prev by Date: RE: [Info-ingres] abf 3gl function
- Next by Date: RE: [Info-ingres] abf 3gl function
- Previous by thread: Re: [Info-ingres] abf 3gl function
- Next by thread: [Info-ingres] Re: Ingres/Replicator Stress Test
- Index(es):
Relevant Pages
|