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.

mohitanchlia@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?

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.

mohitanchlia@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.

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 that informix
creates another buffer called as HDR buffer of same size as Log
Buffer. 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.

mohitanchlia@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 that informix
> 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.
>

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 ? Also, how do I check these threads waiting on L0, L1,
is it onstat -g con or onstat -g ath

mohitanchlia@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

>
>

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 ?

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 ?

Is there a way to see if the network is the bottleneck.

mohitanchlia@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)

>