Hi,

we are moving our application from tru64 to aix. Our application is an
real time application and performance is very important. We are doing
some tests on informix on the new platforms. But replication seem a
bit strange.
test is an 10.000 update row update in a table that has 100.000 row.

We have 2 machine for primary and secondary that has 8 1.8 Ghz core 8
GB memory and a DS4000 storage. The network between them is Gigabit
Ethernet.

informix version IBM Informix Dynamic Server Version 10.00.UC4

Test takes:

6.4 second replication if off
7.1 second asynch replication with DRINTERVAL=0
97 second asynch replication with DRINTERVAL=10

our normal settings is DRINTERVAL=10. We were expecting similar
performance with replication off and asynch repl with DRINTERVAL=10.
But in this test informix seems to having a bug. Our older system is
similar to our expectation.

DRINTERVAL=0 seems to us as workaround.

is it a bug or can some parameter change the result.

Thanks
Yasar Akman

some informix parameters are:
# Shared Memory Parameters

LOCKS 150000 # Maximum number of locks
NUMAIOVPS 2 # Number of IO vps
PHYSBUFF 32 # Physical log buffer size (Kbytes)
LOGBUFF 64 # Logical log buffer size (Kbytes)
CLEANERS 4 # Number of buffer cleaner processes
SHMBASE 0x30000000 # Shared memory base address
SHMVIRTSIZE 160000 # initial virtual shared memory
segment size
SHMADD 8192 # Size of new shared memory segments
(Kbytes)
SHMTOTAL 0 # Total shared memory (Kbytes).
0=>unlimited
CKPTINTVL 300 # Check point interval (in sec)
LTXHWM 50 # Long transaction high water mark
percentage
LTXEHWM 60 # Long transaction high water mark
(exclusive)
TXTIMEOUT 0x12c # Transaction timeout (in sec)
STACKSIZE 128 # Stack size (Kbytes)


# Data Replication Variables
# DRAUTO: 0 manual, 1 retain type, 2 reverse type
DRINTERVAL 10 # DR max time between DR buffer
flushes (in sec)
DRTIMEOUT 30 # DR network timeout (in sec)
DRLOSTFOUND /lcssdata/lcssa/informix/dr.lostfound # DR lost+found
file path

On Nov 8, 8:58 am, Yasar Akman <akman.ya... (AT) gmail (DOT) com> wrote:
Just some thoughts...

You might get some improvements from increasing PHYSBUFF and LOGBUFF
to say 128. This could affect your checkpoint times though.

Also, is each run of your tests really identical, i.e. do you restore
both environments and reinitialise HDR each time? If you don't then
some other factors will influence the test results, like:

.. The content of the buffer pool (cached index pages etc) and the
existence of indexes. Inserting 10,000 rows into an indexed table
already holding 100,000 rows is not comparable to inserting 10,000
rows into the same table already holding, say 500,000 rows. You might
get index cleaning situations etc that will impact the load time.

.. Outdated statistics (Update Stats) on the table and indexes as the
table will grow.

.. The database might break out new extents for the table and any
indexes on unused parts of the SAN that have less than optimal
performance

Among others...


Cheers,

RoB

On Nov 8, 2:58 am, Yasar Akman <akman.ya... (AT) gmail (DOT) com> wrote:
That doesn't seem right to me. DRINTERVAL should be basically the
longest amount of time between sends to the secondary. If you are
doing work and log buffers are filling, as soon as they are filled,
they get sent to the secondary. The only other difference is with
DRINTERVAL set to 0, the thread that is flushing the log buffer
actually waits for a wakeup from the dr_prsend thread indicating the
drbuff has been acknowledged by the secondary. With DRINTERVAL a non
0 value this wait should not be occurring (which is why asynch should
be faster). The thread flushing the logical log buffer would just
copy the contents to a drbuffer and then submit the full drbuffer to
be sent, and then go back to what it was doing previously (which I'd
assume is the updates on the primary). Is it possible that during
your tests that you are checkpointing or something else like that that
might be affecting the update performance?

On 8 Kas m, 16:06, jpren... (AT) yahoo (DOT) com wrote:
It is new machine with 8 core and only this test is running