HP DP GUI painfully, painfully slow

We are on DP 9.06.  My CM is a rx6600.  When I go to to do most anything in the GUI it takes forever or I end of closing and restarting.

 

I am constantly living with the (Not Responding).   There HAS to be a way to speed this up or debug why it is so PAINFULLY slow.

 

Ideas?

Vince

Parents
  • Hi,

    It slow on which actions – and what is the size of data behind such slow query?

    Omnirc OB2_DNSTIMEOUT may help in some cases (set on Cell Server).

    Regards AlesKol

  • Hi Vince,

    can you confirm that you have only actively reachable clients in your Data Protector Clients list (cell_info file)? It is key that the client system (where the GUI is running) is able to contact the clients. This means if some of the clients are only reachable if they exist in /etc/hosts on the Cell Manager this must be the case for the client where GUI is running, too. As @AlesKol mentioned there are omnirc parameters that might help. They should be placed on the Cell Manager. 

    # Enables/Disables DNS Reverse Lookup for xSM
    OB2IPCREVERSELOOKUP=0
    
    # Reduce DNS timeouts from 30 to 3 seconds
    OB2_DNSTIMEOUT=2

    Please use the Accept Solution button next to my post and assign a KUDO (thumbs up icon) if this works for you.

     

    Regards,
    Sebastian Koehler

  • I parsed the cell_info and pulled all the host names out.

    I ran a script to ping each... all came back OK.  I then ran one that did an nslookup, stored the IP, then ran a reverse one.  All came back OK.

    I guess I will have to tweak the other parameters that were recommended and see what happens.

    Stay tuned...  and thanks!

Reply Children
  • Alright. Could you please share how this cell was upgraded to A.09.06?

    Regards,
    Sebastian Koehler

  • I don't recall the details but I do remember following the docs.  Nothing bizarre stands out in my mind.  THAT being said there are still a lot of legacy files that are still around (and that HP really could not help me remove).  The db40 and the underlying dbcf_# files are still ebing touched. 

     

    Vince

  • Please share perl omnimigrate.pl -report_old_catalog to check if the DCBF migration is through or not. I guess SupportOldDCBF=1 is still in your global option file causing lookups to pass db40. Doing this is usually 3 times slower on each DCBF lookup.

    Regards,
    Sebastian Koehler

  • I could have sworn HP had me run the migration.  We don't have ANY backups from 2 years ago in our DP environment.

    (root@sapbck)# ./omnimigrate.pl -report_old_catalog
    Old Detail Catalog Binary Files size:
    DCBF (   0 files):                     0 MB
    Old filename data files:           2780 MB
    Total:                             2780 MB

    Here are all the things set in my .omnirc

    OB2OSTTIMEOUT=7200
    OB2TAPEALERT=0
    OB2SHMEM_IPCGLOBAL=1

    OB2INETTIMEOUT=240
    OB2IPCKEEPALIVE=1

    # SSH was disabled before 3/24/15
    OB2_SSH_ENABLED=1

    # OB2CHANGERELEMENTPARSER=0
    OB2CHANGERELEMENTPARSER=1

    # change debug file location
    OB2DBGDIR=/omniback/debug

    # Added per HP Support 5/5/16
    OB2MADETECTDRIVESWAP=1

    # Added 8/24 per HP forum
    OB2IPCREVERSELOOKUP=0
    OB2_DNSTIMEOUT=2

  • Based on that output you're ready to get rid of the old db40 structure. Please check those items:

    1. Is SupportOldDCBF=1 still in /etc/opt/omni/server/options/global?
    2. Are there still actively used DCBF directories listed in omnidbutil -list_dcdirs (below db40)

    Regards,
    Sebastian Koehler

  • Apparently it is in there twice:

    SupportOldDCBF=0
    # Data Protector A.09.00
    # This value was automatically copied from previous version.
    # This variable is no longer in use.
    SupportOldDCBF=1
    # Data Protector A.09.00
    # This value was automatically copied from previous version.
    # This variable is no longer in use.

    (root@sapbck)# omnidbutil -list_dcdirs
    Configured DC directories:

     Allocation Sequence
     |        Maximum Usage in MB
     |        |        Maximum Number of Files in Directory
     |        |        |        Minimum Free Space [MB]
     |        |        |        |        Directory
     |        |        |        |        |
    ===========================================================================
     0        4096     10000    100      /var/opt/omni/server/db40/dcbf
     0        204800   100000   2048     /omniback/var_opt_omni/server/db80/dcbf/dcbf0
     2        204800   100000   2048     /omniback/var_opt_omni/server/db80/dcbf/dcbf2
     2        4096     10000    100      /var/opt/omni/server/db40/dbcf_2
     1        204800   100000   2048     /omniback/var_opt_omni/server/db80/dcbf/dcbf1
     1        4096     10000    100      /var/opt/omni/server/db40/dbcf_1
     3        204800   100000   2048     /omniback/var_opt_omni/server/db80/dcbf/dcbf3
     4        204800   100000   2048     /omniback/var_opt_omni/server/db80/dcbf/dcbf4

    DONE!

  • Please make sure no sessions are running and do the following.

    1. Run omnidbutil -remap_dcdir. If no error is returned, move all DCBFs from /var/opt/omni/server/db40/dcbf, /var/opt/omni/server/db40/dbcf_1 and /var/opt/omni/server/db40/dbcf_2 to any of the other DCBF folders (e.g. /omniback/var_opt_omni/server/db80/dcbf/dcbf0) and run omnidbutil -remap_dcdir again.
    2. Then run omnidbutil -remove_dcdir /var/opt/omni/server/db40/dcbf, omnidbutil -remove_dcdir /var/opt/omni/server/db40/dcbf_1 and omnidbutil -remove_dcdir /var/opt/omni/server/db40/dcbf_2.
    3. Remove both instances of SupportOldDCBF from global file and restart the services (omnisv stop, omnisv start).
    4. Then it is save to remove the old catalog using perl omnimigrate.pl -remove_old_catalog. The directory structure /var/opt/omni/server/db40 can be removed afterwards.

    Please use the Accept Solution button next to my post and assign a KUDO (thumbs up icon) if this works for you.

    Regards,
    Sebastian Koehler

  • Sebastian, I am observing this discussion and I have a question about the redistribution. You say move the DCBFs in the DB40 dir, do you mean the *.dat files or the Dirs themselves. I should not be having data go there, but it is. I would like to eleminate the DB40.

    omnidbutil -list_dcdirs
    Configured DC directories:

    Allocation Sequence
         | Maximum Usage in MB
                  | | Maximum Number of Files in Directory
                          | | | Minimum Free Space [MB]
                                            | | | | Directory
                                                                          | | | | |
    ===========================================================================
    1 4096 10000 100 /var/opt/omni/server/db40/dcbf2
    3 4096 10000 100 /var/opt/omni/server/db40/dcbf4
    2 4096 10000 100 /var/opt/omni/server/db40/dcbf3
    1 204800 100000 2048 /var/opt/omni/server/db80/dcbf/dcbf1
    0 4096 10000 100 /var/opt/omni/server/db40/dcbf
    4 204800 100000 2048 /var/opt/omni/server/db80/dcbf/dcbf4
    0 204800 100000 2048 /var/opt/omni/server/db80/dcbf/dcbf0
    3 204800 100000 2048 /var/opt/omni/server/db80/dcbf/dcbf3
    2 204800 100000 2048 /var/opt/omni/server/db80/dcbf/dcbf2

  • Hi Tommy,

    you need to move the *.dat files stored in the directories. Please make sure to run omnidbutil -remap_dcdir before and after. If you find any issues with the command, report back.

    It is expected that new DCBFs also go into the "old directory" structure. This depends on how DCDirAllocation in the global option file is configured. This does not hurt, but it should be taken into account when removing db40.

    Regards,
    Sebastian Koehler