HDR - Waiting on logical-log buffer

we have a strange behaviour on our HDR on Solrais Sparc with IDS 9.40.FC4. When the secondary server is not available, work is OK without problems. If the secondary server is available, but behind a firewall, users are getting more and more problems. onstat -u shows increasing number of sessions with a flag "G" (Waitingfor a write of the logical-log buffer". We work with DR_INTERVAL 30, so i did not expect any waiting conditions on the primary server. Any idea ? -- best regards, Gerd \\\\\\\\|// (o o) --------------------------------------------------ooO-(_)-Ooo--- Gerd Kaluzinski mailto:support@bytec.de http://www.bytec.de BYTEC GmbH Telefon: 07541-585-1019 Hermann-Metzger-Str. 7 Fax : 07541-585-2019 88045 Friedrichshafen Ooo. -------------------------------------------------.ooO----( )--- ( ) (_/ \\\\_)

Gerd, in HDR, when logical log buffers get flushed to disk, they also get transferred to HDR secondary. If secondary is not able to process the logical log records as fast as they are produced on primary, and primary's HDR buffering might get filled up, and sqlexec threads on primary may have to wait. You can verify this situation by running onstat -g ath, and check if sqlexec threads are waiting on a condition "drcb_bqe", which means sqlexec thread is waiting for an empty buffer arriving in the HDR buffer queue. Also, pls check what secondary's dr_secrcv and dr_secapply threads are waiting for. You mentioned a firewall. Is the same problem appearing also without a firewall? Thanks, Karl -- Karl Ostner IBM Informix Development Munich Information Management IBM Software Group e-mail: kostner@de.ibm.com "Gerd Kaluzi...." <gerd.kaluzinski@ bytec.de> To Sent by: ids@iiug.org forum.subscriber@ cc iiug.org Subject HDR - Waiting on logical-log buffer 02.02.2005 09:18 [4135] AM we have a strange behaviour on our HDR on Solrais Sparc with IDS 9.40.FC4. When the secondary server is not available, work is OK without problems. If the secondary server is available, but behind a firewall, users are getting more and more problems. onstat -u shows increasing number of sessions with a flag "G" (Waitingfor a write of the logical-log buffer". We work with DR_INTERVAL 30, so i did not expect any waiting conditions on the primary server. Any idea ? -- best regards, Gerd \\\\\\\\|// (o o) --------------------------------------------------ooO-(_)-Ooo--- Gerd Kaluzinski mailto:support@bytec.de http://www.bytec.de BYTEC GmbH Telefon: 07541-585-1019 Hermann-Metzger-Str. 7 Fax : 07541-585-2019 88045 Friedrichshafen Ooo. -------------------------------------------------.ooO----( )--- ( ) (_/ \\\\_)

Gerd, regarding the firewall, its out of my scope to assess the impact :-( Does the firewall affect the performance of other applictions under heavy load situations also? Regarding HDR, you are absolutely correct on the effect of DR_INTERVAL (synchronous / asynchronous). In synchronous mode, secondary is logically acknowleding the receiving of the logical log data, and sqlexec thread has to wait for that. But the problem might be caused in a lower layer. Lets consider that due to some circumstances (e.g. slow network connection, slow processing of log records on secondary) the HDR primary's dr_prsend thread is not able to send log data to secondary as fast as it gets produced. In this case, the data to send is buffered on primary up to some amount (this is not configurable). If the buffers get full, sqlexec threads cannot get new (empty) buffers, but have to wait for them. If sqlexec thread is "cond wait drcb_bqe", we are facing this case. The setting of DR_INTERVAL has no effect on this situation. Have you seen DR ping timeout messages in online.log more frequently when a firewall is place? HTH, Karl -- Karl Ostner IBM Informix Development Munich Information Management IBM Software Group e-mail: kostner@de.ibm.com Gerd Kaluzinski <gerd.kaluzinski@ bytec.de> To Karl Ostner/Germany/IBM@IBMDE 02.02.2005 12:13 cc PM forum.subscriber@iiug.org, ids@iiug.org Subject Please respond to Re: HDR - Waiting on logical-log gerd.kaluzinski buffer [4135] Hi Karl, thank you for the response. The first 2 weeks, the secondary was inside the firewall and at this time, there have been no problems with performance, so i think the real problem is somewhat handline with the firewall. My problem is to understand why the server is waiting for the secondary to acknoledge the lognub write when i configured DR_INTERVAL to 30. With DR_INTERVAL 0 or even -1 i would have expected that behaviour. To be able to work, we have shut down HDR using onmode -d standard, so i cannot look at the onstat -g ath at this time. thanks, gerd Karl Ostner wrote: > > >Gerd, > >in HDR, when logical log buffers get flushed to disk, they also >get transferred to HDR secondary. If secondary is not able to >process the logical log records as fast as they are produced >on primary, and primary's HDR buffering might get filled up, and >sqlexec threads on primary may have to wait. You can verify this >situation by running onstat -g ath, and check if sqlexec threads >are waiting on a condition "drcb_bqe", which means sqlexec thread >is waiting for an empty buffer arriving in the HDR buffer queue. >Also, pls check what secondary's dr_secrcv and dr_secapply threads >are waiting for. > >You mentioned a firewall. Is the same problem appearing also >without a firewall? > >Thanks, > > Karl >-- >Karl Ostner >IBM Informix Development Munich >Information Management >IBM Software Group >e-mail: kostner@de.ibm.com > > > > "Gerd Kaluzi...." > <gerd.kaluzinski@ > bytec.de> To > Sent by: ids@iiug.org > forum.subscriber@ cc > iiug.org > Subject > HDR - Waiting on logical-log buffer > 02.02.2005 09:18 [4135] > AM > > > > > > > > > >we have a strange behaviour on our HDR on Solrais Sparc with IDS 9.40.FC4. >When the secondary server is not available, work is OK without problems. >If the secondary server is available, but behind a firewall, users are >getting more and more problems. >onstat -u shows increasing number of sessions with a flag "G" (Waiting>for a write of the logical-log buffer". >We work with DR_INTERVAL 30, so i did not expect any waiting conditions >on the primary server. > >Any idea ? > >-- >best regards, > >Gerd > \\\\\\\\|// > (o o) >--------------------------------------------------ooO-(_)-Ooo--- >Gerd Kaluzinski mailto:support@bytec.de > http://www.bytec.de >BYTEC GmbH Telefon: 07541-585-1019 >Hermann-Metzger-Str. 7 Fax : 07541-585-2019 >88045 Friedrichshafen Ooo. >-------------------------------------------------.ooO----( )--- > ( ) (_/ > \\\\_) > > > > > > >