Re: HDR recommendations

On Aug 25, 3:41 pm, Madison Pruet <mpru...@verizon.net> wrote: > mohitanch...@gmail.com wrote: > > On Aug 25, 4:12 am, Madison Pruet <mpru...@verizon.net> wrote: > >> mohitanch...@gmail.com wrote: > >>> On Aug 24, 4:15 pm, Madison Pruet <mpru...@verizon.net> wrote: > >>>> mohitanch...@gmail.com wrote: > >>>>> On Aug 24, 9:59 am, Madison Pruet <mpru...@verizon.net> wrote: > >>>>>> mohitanch...@gmail.com wrote: > >>>>>>> On Aug 23, 8:45 pm, Madison Pruet <mpru...@verizon.net> wrote: > >>>>>>>> mohitanch...@gmail.com wrote: > >>>>>>>>> Could somebody tell me their experiences about HDR. I am reading about > >>>>>>>>> HDR to see where we can improve. We ran our tests and the performance > >>>>>>>>> was less than .5 of what we generally get. Do things like log file > >>>>>>>>> size make difference ? Would increasing memory help ? We have huge > >>>>>>>>> blobs being replicated. > >>>>>>>> You're going to need to be a bit more specific. > >>>>>>>> Are you currently using HDR and want to improve existing performance, or > >>>>>>>> are you just starting with HDR? > >>>>>>>> Are you using sync mode? > >>>>>>>> Are you using unbuffered logging? > >>>>>>>> What is your network like? > >>>>>>>> Are you doing single row update transactions? > >>>>>>> Version: IDS 10 > >>>>>>> 1. HDR in sync mode > >>>>>>> 2. Buffered logging > >>>>>>> 3. fibre optic > >>>>>>> 4. Single row update > >>>>>>> 5. We have BYTE type as part of the tabpespace because HDR can't > >>>>>>> replicate Blobspaces. > >>>>>>> And yes, I am looking for something that will improve the performance, > >>>>>>> because as it is right now it's very slow. We also discussed of ASYNC > >>>>>>> mode but are concerned about potential impact on Data that we might > >>>>>>> lose in an event of failure. > >>>>>> You already risk losing committed transactions because you are using > >>>>>> buffered logging. > >>>>>> Let's consider the impact of using sync mode (DRINTERVAL -1). Basically > >>>>>> what this does is to block the log flush until the log buffer being > >>>>>> flushed has been transmitted to the secondary node and ACKed. The ACK > >>>>>> occurs once the log buffers have been placed in the HDR receive queue on > >>>>>> the secondary. Depending on the ability to process the logs on the > >>>>>> secondary, the ACK can occur as soon as the log buffer is received, but > >>>>>> it might also have to wait for a log buffer to become available if the > >>>>>> secondary is overloaded. Only after the ACK has been received can the > >>>>>> log buffer on the primary be marked as empty and ready for reuse. > >>>>>> If most of your log activity involves tablespace blobs, then I suspect > >>>>>> that the log buffer would fill up fairly quickly, but you might want to > >>>>>> consider making sure that things are not backing up on the primary too > >>>>>> much (look for threads waiting on L0, L1, L2) That's an indication that > >>>>>> the logs are not being flushed quickly enough and since HDR is part of > >>>>>> the log flush in a SYNC HDR system, then that can also indicate a > >>>>>> backflow issue. If that is happening, the make sure that the secondary > >>>>>> has enough horse-power to keep up with the primary. > >>>>>> Another thing to consider is the size of each buffer. Since HDR is > >>>>>> using a half-duplex communication model, it is desirable to try to get > >>>>>> each ACK to cover as much log data as possible. The way to do that is > >>>>>> to make sure that your log buffer is fairly large. Of course, this > >>>>>> might also mean that you want to consider using unbuffered logging > >>>>>> rather than buffered logging.- Hide quoted text - > >>>>>> - Show quoted text - > >>>>> I am assuming that your advise is to increase the log buffer size of > >>>>> Secondary node. I was reading about HDR and it appears thatinformix > >>>>> creates another buffer called as HDR buffer of same size as Log > >>>>> Buffer. > >>>> The log buffers have to be the same size. > >>>> So I am assuming increasing the size of log buffer on > >>>>> secondary node will allow primary server to have lesser wait time > >>>>> because it will be able to find free buffer faster. > >>>>> According to IBM HDR is full duplex, could you also point me to some > >>>>> place that gives more information about it. > >>>> Where did you get that piece of information? It's just not true. The > >>>> IDS11 SDS and RSS connections are full duplexed, but not the HDR. ER is > >>>> also full duplexed. > >>> Yes. you are correct. I got mixed up with IDS 11 RSS (SMX). Regarding > >>> increasing the buffer size on secondary node how should I calculate > >>> the correct size. I was thinking of increasing it to 64K from 48K on > >>> secondary node. Also, you mentioned making the logging unbuffered. > >>> Could it be made unbuffered just on secondary node, and if yes then > >>> would it help? > >> no - the purpose of doing this is that by using buffered logging you are > >> exposing yourself to potential loss of committed transactions if the > >> server should fail. By using unbuffered logging, that is not going to > >> happen. I was concerned that by increasing the size of the log buffer, > >> you also would be increasing the risk. > > >> Also, how do I check these threads waiting on L0, L1, > > >>> is it onstat -g con or onstat -g ath > >> onstat -g ath> > > I was thinking, probably increasing buffer size on secondary node has > > less potential impact and might increase the performance because > > primary server will be able to find the free pages in buffer faster > > and thus will get the ack of receipt of logs faster. Only impact would > > be when something happens to primary node, in that case, secondary > > server might take some time to write those logs to disk. Am I making > > sense ? > > The size of the log buffers must be the same on the primary as the > secondary. > > > > > Also, as I understand there are 2 threads for HDR one that keeps > > pinging the servers and another that sends or receives the logs. Does > > it affect the performance too ? > > not really. > > > > > Is there a way to see if the network is the bottleneck. > > I would not worry about that. I would worry about the backflow into the > log flushing process. (waiting on L0, L1, L2) > > > > - Hide quoted text - > > - Show quoted text -- Hide quoted text - > > - Show quoted text - While running in HDR I checked for threads in L0, L1 ..but didn't see any. I did see flush_sb(0). Is there a better way to monitor how logical logs are being shipped, how big the logical log buffer is and how long does it take to get free page in that buffer ?