Forum Discussion

Zahid_Haseeb's avatar
Zahid_Haseeb
Moderator
12 years ago
Solved

What is the compression ratio or algorithm used in VVR replication

Environment

SFHA/DR = 6.0.2

OS = Win2008R2

  • See extract from VVR admin guide:

    VVR uses the zlib library for performing compression and decompression. For
    more information on the zlib compression library, see http://www.zlib.net

    zlib uses the "Deflate" algorithm see http://www.zlib.net/feldspar.html  for more information.

    Memory is allocated from the VVR NMCOM memory pool 

    Mike

  • Hi Zahid,

    The VVR compression ratio is dependent on the data being compressed.  VVR uses the NMCom memory pool on the primary to compress the packet being sent.  It then compares the compressed packet in NMCom memory to uncompressed packet in the RDBack pool memory and sends the one that is smaller or the one in the RDBack pool if they are the same size.

    You can use the "rlink -e -i 5 stats <rlink_name>" command on the primary to details on compression that is being done live on the server.

    "vxtune" command output also shows some of the tunables that can be done with compression. 

    I have adjusted the number of threads with a few customers but not many.  The more threads that you allocate to compression the more load it puts on the servers.  It does not change compression ratios.

    If you adjust any tunables alway check your vxmemstat output to see how your memory is doing.  If you are hitting max memory then you should think about increasing memory to NMCom or RDBack pool as needed on the primary and secondary.

    Thank you,

    Wally

     

  • Hi Zahid,

    Compression ratio is as such not defined as what exact ratio is being used. I am assuming it would be hard coded.

    From Admin guide

    Compression feature enables VVR to send data in a compressed form from a
    PrimarytoaSecondaryhost.ItreducesnetworkbandwidthconsumptionbyVVR.
    This feature is particularly useful in scenarios where there is low availability of
    bandwidth or where the bandwidth is shared among several applications.
    Purchasing an external compression software or hardware for data transfer can
    prove costly. Hence, compression feature in VVR is a cost-effective alternative in such scenarios.
     
    Compression option can be enabled on a per RLINK basis either through the CLI
    or GUI. If both sides have compression enabled, the Primary site generates the
    compresseddataduringsendingofanyupdates.Atanytime,theusercandisable
    or enable the compression feature without stopping replication.
    GeneralfunctionalityconstraintsforVVRcompressionareasshown.Datashould
    not be send in compressed form in the following cases:
    If either the Primary or Secondary RLINK does not have compression enabled
    If the compressed data size is greater than the uncompressed data size
    If the memory for keeping the compressed data could not be allocated on the
    Primary side
     
     
    G

     

  • Thanks Gaurav for your words.

    If the memory for keeping the compressed data could not be allocated on the
    Primary side

    I never see the memory allocation when configuring the replication (via VEA) between primary and DR site.

    =============

    So, when the compress replication data reaches at DR site it first uncompress replication data and then it writes to DR site volume. Correct ?

  • Yes, that is correct, data is compressed only to save the bandwidth, it will be uncompressed again before getting written to the volumes on DR site.

    About, memory, I don't believe you would be able to see any specific memory allocation happening for compression, rather the memory used by VVR itself will be shared.

     

    G

  • See extract from VVR admin guide:

    VVR uses the zlib library for performing compression and decompression. For
    more information on the zlib compression library, see http://www.zlib.net

    zlib uses the "Deflate" algorithm see http://www.zlib.net/feldspar.html  for more information.

    Memory is allocated from the VVR NMCOM memory pool 

    Mike

  • Hi Zahid,

    The VVR compression ratio is dependent on the data being compressed.  VVR uses the NMCom memory pool on the primary to compress the packet being sent.  It then compares the compressed packet in NMCom memory to uncompressed packet in the RDBack pool memory and sends the one that is smaller or the one in the RDBack pool if they are the same size.

    You can use the "rlink -e -i 5 stats <rlink_name>" command on the primary to details on compression that is being done live on the server.

    "vxtune" command output also shows some of the tunables that can be done with compression. 

    I have adjusted the number of threads with a few customers but not many.  The more threads that you allocate to compression the more load it puts on the servers.  It does not change compression ratios.

    If you adjust any tunables alway check your vxmemstat output to see how your memory is doing.  If you are hitting max memory then you should think about increasing memory to NMCom or RDBack pool as needed on the primary and secondary.

    Thank you,

    Wally