ADSM-L

Re: [ADSM-L] Sloooow deletion of objects on Replication target server

2017-07-25 13:35:39
Subject: Re: [ADSM-L] Sloooow deletion of objects on Replication target server
From: Stefan Folkerts <stefan.folkerts AT GMAIL DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Tue, 25 Jul 2017 19:34:02 +0200
My question would be on what type of storage is the Spectrum Protect
database located.
Second question, have you run the IBM blueprint benchmark tool on the
storagepool and database storage, and if so, what were the results?

On Mon, Jul 24, 2017 at 3:55 PM, Sasa Drnjevic <Sasa.Drnjevic AT srce DOT hr>
wrote:

> Not sure of course...But, I would blame NFS
>
> Did you check the negotiated speed of your NFS eth 10G ifaces?
> And that network?
>
> Regards,
>
> --
> Sasa Drnjevic
> www.srce.unizg.hr
>
>
> On 24.7.2017. 15:49, Zoltan Forray wrote:
> > 8-cores/16-threads.  It wasn't bad when it was replicating from 4-SP/TSM
> > servers.  We had to stop all replication due to running out of space and
> > until I finish this cleanup, I have been holding off replication.  So,
> the
> > deletion has been running standalone.
> >
> > I forgot to mention that DB backups are also running very long.  1.5TB DB
> > backup runs 8+hours to NFS storage.  These are connected via 10G.
> >
> > On Mon, Jul 24, 2017 at 9:41 AM, Sasa Drnjevic <Sasa.Drnjevic AT srce DOT 
> > hr>
> > wrote:
> >
> >> On 24.7.2017. 15:25, Zoltan Forray wrote:
> >>> Due to lack of resources, we have had to stop replication on one of our
> >> SP
> >>> servers. The replication target server is 7.1.6.3 RHEL 7, Dell T710
> with
> >>> 192GB RAM.  NFS/ISILON storage.
> >>>
> >>> After removing replication from the nodes on source server, I have been
> >>> cleaning up the replication server by deleting the filespaces for the
> >> nodes
> >>> we are no longer replicating.
> >>>
> >>> My issue is the delete filespaces on the replication server is taking
> >>> forever.  It took over a week to delete one filespace with 31-million
> >>> objects?
> >>
> >>
> >> That is definitely tooooo loooong :-(
> >>
> >> It would take 6-8 hrs max, in my environment even under "standard"
> load...
> >>
> >> How many CPU cores does it have?
> >>
> >> And how is/was it performing the role of a target repl. server
> >> performance wise?
> >>
> >> Regards,
> >>
> >> --
> >> Sasa Drnjevic
> >> www.srce.unizg.hr
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >>>
> >>> To me it is highly unusual to take this long. Your thoughts on this?
> >>>
> >>> --
> >>> *Zoltan Forray*
> >>> Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator
> >>> Xymon Monitor Administrator
> >>> VMware Administrator
> >>> Virginia Commonwealth University
> >>> UCC/Office of Technology Services
> >>> www.ucc.vcu.edu
> >>> zforray AT vcu DOT edu - 804-828-4807
> >>> Don't be a phishing victim - VCU and other reputable organizations will
> >>> never use email to request that you reply with your password, social
> >>> security number or confidential personal information. For more details
> >>> visit http://infosecurity.vcu.edu/phishing.html
> >>>
> >>
> >
> >
> >
> > --
> > *Zoltan Forray*
> > Spectrum Protect (p.k.a. TSM) Software & Hardware Administrator
> > Xymon Monitor Administrator
> > VMware Administrator
> > Virginia Commonwealth University
> > UCC/Office of Technology Services
> > www.ucc.vcu.edu
> > zforray AT vcu DOT edu - 804-828-4807
> > Don't be a phishing victim - VCU and other reputable organizations will
> > never use email to request that you reply with your password, social
> > security number or confidential personal information. For more details
> > visit http://infosecurity.vcu.edu/phishing.html
> >
>


ADSM.ORG Privacy and Data Security by KimLaw, PLLC