DX Unified Infrastructure Management

  • 1.  ATTACH QOS queue draining extremely slow of remote HUB

    Posted Jan 22, 2018 03:10 AM

    We are facing issues with ATTACH QOS queue of remote HUB, this queue sending QOS data to its reporting HUB and GET queue on the receiver HUB is absolutely fine.

    Due to the slowness huge data have been queued up in the queue.

    We have increased the bulk_size of the queue to 1000 also restarted HUBs to see if anything improves.

    However its still draining extremely slowly

    Please let us know what can we do to improve the performance or we need to create another queue as this one seems to be corrupted as have seen this earlier also.

     

    Regards,

    Manish Sharma



  • 2.  Re: ATTACH QOS queue draining extremely slow of remote HUB

    Posted Jan 22, 2018 05:39 AM

    Hello!

     

    Try to see if this parameters will help.

     

    Edit the hub.cfg and find the <hub> section. In that section, adjust the following keys (most should exist already, but if any do not, you may add them.)

     

    postroute_interval = 120
    postroute_reply_timeout = 180
    postroute_passive_timeout = 300
    hub_request_timeout = 120
    tunnel_hang_timeout = 300
    tunnel_hang_retries = 3

     

    On systems with very low latency and fast response between hubs, it may be beneficial to decrease tunnel_hang_timeout to 120, or even 60.



  • 3.  Re: ATTACH QOS queue draining extremely slow of remote HUB

    Posted Jan 22, 2018 06:14 AM

    Hi Alex,

     

    We have already made these changes in HUB.cfg but nothing has improved, please let us know if we can do anything to fix the issue.

     

    Regards,

    Manish Sharma



  • 4.  Re: ATTACH QOS queue draining extremely slow of remote HUB

    Broadcom Employee
    Posted Jan 22, 2018 04:10 PM

    If you have high latency between the 2 hubs, there is a tunnel connecting them, and you have hub 7.92HF6 or later installed on the two hubs, you can try implementing data compression on the sending hub to see if that resolves the data backup on the sending hub.

     

    The instructions for doing this included below were taken from the hub 7.93 release notes where this is described:

     

    • (7.92HF6) To improve the throughput performance of tunnel communication between hubs in a high latency network, data compression can now be configured.

      • Hubs that send data can be configured to compress the data before it is sent through a tunnel to a receiving hub. Install this fix and configure the tunnel to enable compression on sending hubs where network latency is an issue.
      • Install this fix on every receiving hub connected by a tunnel to a sending hub that is running this fix with compression enabled.
      • You enable compression and configure the level of compression on sending hubs. When the fix is installed on receiving hubs, compression is automatically detected and messages are automatically decompressed.
      • To enable compression on a sending hub, take the following steps:
        1. In Infrastructure Manager or Admin Console, stop the sending hub.
        2. On the sending hub, edit the hub configuration file, $UIMHOME/hub/hub.cfg.
          1. Add the new key tunnel_compression in the /tunnel section of hub.cfg. Default, 0.
            • A value of 0 specifies that tunnel compression is off.
            • A value of 1 specifies that tunnel compression is on.
          2. (Optional) Add the new key compression_level in the /tunnel section of hub.cfg.
            • Set the value between 0 and 9. Default, 0.
              • A value of 0 specifies the least level of compression.
              • A value of 9 specifies the greatest level of compression. Higher levels of compression reduce network traffic, but take additional time to construct.
          3. (Optional) Add the new key min_compression_size in the /tunnel section of hub.cfg. The key specifies the  message size that will be compressed. Default, 1400b.
        3. Save your changes to hub.cfg.
        4. In Infrastructure Manager or Admin Console, start the hub.
        5. To verify that the compression is working, search both hub log files, hub.log.
          1. At log level 1, a log entry indicates the state of compression, compression=value. Compression is off when the value is 0, and compression is on when the value is 1.
          2. At log level 5, the log contains an entry for each compressed or decompressed PDS:
            1. Sender log message:
              • compressPDS:<num> bytes compressed to <num>
            2. Receiver log message:
              • decompressPDSs: HEAD <num> bytes decompressed to <num>
                • or
              • decompressPDSs: BODY <num> bytes decompressed to <num>