Replication performance problem related with DRINTERVAL

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 memorysegment 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 markpercentage 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+foundfile path

On Nov 8, 8:58 am, Yasar Akman <akman.ya...@gmail.com> wrote: > 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 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...@gmail.com> wrote: > 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 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...@yahoo.com wrote: > On Nov 8, 2:58 am, Yasar Akman <akman.ya...@gmail.com> wrote: > > > > > > > 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 > > 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?- Al nt y gizle - > > - Al nt y g'ster - It is new machine with 8 core and only this test is running