Sergio,
I don't have exact numbers but from what I recall we were running
150-200MB/s, this is not the network load but the effective thruput using
client-side deduplication.
Use multiple sessions (how many is best is trial/error) and have fast
filepool storage as well, you will see a lot of reads on the filepool
because TSM reads the data before calling "I got the data stored" on the
TSM server.
If the filepool storage is slow you will see a high wait i/o because of
this, I have seen the random read speed of the filepool be the bottleneck
with client-side dedup due to high wait I/O's (30%+)
Regards,
Stefan
On Wed, Jan 21, 2015 at 11:33 PM, Sergio O. Fuentes <sfuentes AT umd DOT edu>
wrote:
> Thanks for the feedback. If you've successfully done source-side dedup
> with an SSD-backed TSM DB with Oracle TDP, can you provide any indication
> of the transfer rates that you can see? Like, would you be able to
> successfully backup a 100GB DB in say less than an hour. That would be
> about 27 MB/sec? I'm currently seeing rates of 3MB/sec. Pretty pitiful.
>
> Our DB is on an auto-tiering VMAX (FAST VP) backed by about 1TB of Flash.
> FAST VP transfers the hotspots to Flash normally dictated by some
> secret-sauce formula of read-rates and cache misses or something to that
> effect. I have very little I/O wait coming from the TSM server DB's
> during the TDP backup. I'll have to check on the client to see if there's
> a bottleneck there.
>
> Thanks again!
> Sergio
>
>
> On 1/21/15, 4:16 AM, "Stefan Folkerts" <stefan.folkerts AT GMAIL DOT COM>
> wrote:
>
> >What type of storage are you using for the TSM database?
> >I've seen client-side dedup running fast for databases with SSD's for TSM
> >database and activelog but not so much with traditional harddrives, even
> >if
> >it was bunch of 15K disks, it just doesn't deliver like 4 SSD's.
> >
> >From what I have seen you pretty much require SSD's for the TSM database
> >if
> >you want any serieus performance on client-side deduped structured data
> >backups that want to stream a lot of data. Also for client-side dedup of
> >VM's when you are backing up a lot of them at the same time.
> >
> >File-level incrementals have a different impact because there is
> >filesystem
> >scanning going on to somewhat relieve the TSM DB disk iop/s wise, start a
> >few databases with client-side dedup and see the wait i/o increase
> >significantly if you don't use SSD's.
> >
> >This is just my experience from a few customer sites.
> >
> >
> >
> >On Tue, Jan 20, 2015 at 10:07 PM, Sergio O. Fuentes <sfuentes AT umd DOT edu>
> >wrote:
> >
> >> Hello folks,
> >>
> >> I've been using source-side deduplication pretty successfully for most
> >>of
> >> my clients (Unix and Windows and TDP for MSSQL) for at least two years
> >> now. The backup window for the source-side is significantly shorter for
> >> Unix clients, minimally shorter for Windows and somewhat longer for
> >>MSSQL
> >> nodes on average. The pain I've been having is with Oracle RMAN and
> >>TDP.
> >> I'm unsure if our older Oracle servers are just really undersized or if
> >> it's a function of TSM dedup overhead while doing source-side dedupe
> >>that
> >> is expanding the backup window way too long. I have tested several
> >> versions of TSM against several versions of Oracle (10 and 11) on
> >>several
> >> different hardware Oracle Solaris tiers. I wanted to see if anyone in
> >>the
> >> group has had any significant achievements with source-side dedup and
> >> Oracle DB's. Am I being overly optimistic with TSM or TDP and its
> >>ability
> >> to process over 100GB of DB data for one node for a level 0? Our
> >>databases
> >> are not that large, with the largest being about 400GB (and doing level
> >>0's
> >> on that thing is a nightmare).
> >>
> >> Here's some info on the environment settings that I'm currently testing
> >>
> >> Deduplication ON in TSM and Client
> >> Compression ON in TSM
> >> Filesperset 1 in Oracle for Data files
> >> Filesperset 10 in Oracle for Archive logs
> >> Archive and Data files are both processed for dedup (I don't like the
> >> complexity of managing a non-dedup storage tier just for logs, so I'll
> >>try
> >> to eat the overhead on that)
> >> TSM API at 7.1.1.0
> >> TDP Version at 6.3.0
> >> RMAN version ?
> >> Oracle version 10, moving to 11 but having same performance issues
> >> TSM catalog is on an auto-tiering SAN array with flash.
> >>
> >> Right now, my failback is to do post-process deduplication and that's
> >> worked out fine, but I really want to see what kind of ingestion rates
> >>we
> >> should be able to see with Oracle RMAN and TSM source-side
> >>deduplication.
> >>
> >> Also, I'm not shelling out money for a VTL right now. The decision was
> >>to
> >> stick with TSM Dedup and aside from nagging clients like Orace RMAN and
> >> TDP, I've had no issues with TSM dedup. (Running a TSM server on
> >>Solaris
> >> was awful, however).
> >>
> >> Thanks!
> >> Sergio
> >>
>
|
