Re: Log compression for replication ??

Jack, I'm more concerned with the reasons for the buildup in the TCP send queue than with trying to implement network compression for this. I'd like to see this worked a bit so that we can find out where the bottleneck actually is. The HDR receive thread on the secondary should be receiving log pages from the network and putting them into the replay log buffers on the secondary where the apply is spread across several recovery threads. So I'm a bit suprised that the secondary would not be able to receive the buffers as fast as the primary is creating them. Please open a case on this and let's see what the secondary is doing at the time that this is occuring. On thing to consider. The primary is sending log pages. Therefor, you can get an idea how much traffic HDR is sending by examining the size of the log file (onstat -l) and then determining how many log files are used per hour from the message log file. M.P. "Jack A" <hrehal@yahoo.com> wrote in message news:5b83c3e5548b78f5201f76f39bc79d8d@news.teranews.com... > As I mentioned a few days ago, replication traffic has spiked up on our > network. It was because of periodic purges that were running. This is > becoming a big issue in my company that we are eating up bandwidth because > online users get bloced. Is there any way to have Informix compress the logs > before they are shipped out to the secondary ? I've looked through the > manuals and havent found anything and was surprised. > > This might be a good enhancement to suggest to the Informix development > group. > > TIA, > Jack > >

I compiled some statistics by checking on the logs being sent as you mentioned. We run HDR over a WAN. We run purges over the weekends and that causes a huge spike in traffic because there is lots of data being purged. We have a 3MB pipe for our WAN. On the busiest day our traffic is about 132 MB ( 33 log files @ 4K each ) . When we did our purges this spiked to 400MB ( 100 logs ). This is good enough to choke our bandwitdth. I'm thinking this is the cause of most of the bottle necks. "Madison Pruet" <mpruet@comcast.net> wrote in message news:ZKs%a.156997$o%2.66451@sccrnsc02... > Jack, > > I'm more concerned with the reasons for the buildup in the TCP send queue > than with trying to implement network compression for this. I'd like to see > this worked a bit so that we can find out where the bottleneck actually is. > > The HDR receive thread on the secondary should be receiving log pages from > the network and putting them into the replay log buffers on the secondary > where the apply is spread across several recovery threads. So I'm a bit > suprised that the secondary would not be able to receive the buffers as fast > as the primary is creating them. Please open a case on this and let's see > what the secondary is doing at the time that this is occuring. > > On thing to consider. The primary is sending log pages. Therefor, you can > get an idea how much traffic HDR is sending by examining the size of the log > file (onstat -l) and then determining how many log files are used per hour > from the message log file. > > M.P. > "Jack A" <hrehal@yahoo.com> wrote in message > news:5b83c3e5548b78f5201f76f39bc79d8d@news.teranews.com... > > As I mentioned a few days ago, replication traffic has spiked up on our > > network. It was because of periodic purges that were running. This is > > becoming a big issue in my company that we are eating up bandwidth because > > online users get bloced. Is there any way to have Informix compress the > logs > > before they are shipped out to the secondary ? I've looked through the > > manuals and havent found anything and was surprised. > > > > This might be a good enhancement to suggest to the Informix development > > group. > > > > TIA, > > Jack > > > > > >