ADSM-L

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

2017-07-24 09:57:22
Subject: Re: [ADSM-L] Sloooow deletion of objects on Replication target server
From: Sasa Drnjevic <Sasa.Drnjevic AT SRCE DOT HR>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Mon, 24 Jul 2017 15:55:34 +0200
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