How many drives in what kind of a raid setup? what kinds of performance are
you getting from them, do you have any idea?
I have had nothing but issues with performance on deduplicating setups,
especially with replication in play when you use 15K disks.
I've had setups with 24x15K drives in raid 10 in a V7000 and I still was
having a hard time getting all the work done, as soon as you drop in some
SSD's you set, but I suppose they can work on small setups.
I would never use 15K drives again for any kinds of disk based
deduplicating setup however, SSD's are not that expensive anymore, you can
use read intensive SSD's in most cases and be fine.
Really, the blueprint benchmark tool works fine and gives a good indication
of your base disk performance, if it's far below what's described for the
blueprint that's probably the problem.
I would put my money on the 15K drives for the database and my suggestion
(in the case of insufficient database performance) would be place the
database and the active log on SSD's
On Tue, Jul 25, 2017 at 7:58 PM, Zoltan Forray <zforray AT vcu DOT edu> wrote:
> The two database filesystems (1TB each) are on internal, 15K SAS drives.
>
> On Tue, Jul 25, 2017 at 1:34 PM, Stefan Folkerts <
> stefan.folkerts AT gmail DOT com>
> wrote:
>
> > 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
> > > >
> > >
> >
>
>
>
> --
> *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
>
|
