We're running about 200 nodes, another 320-ish (it varies day by day) VMs
with an average daily intake of 4.2 TB over the past 30 days.  We have a
high change-rate, however, and our occupancy is 'only' 270 TB and around
110,000,000 objects stored.

We back up directly to the dedup pool, which resides on a mix of 3 and 4
TB NL-SAS disks hosted on a V7000 and a DCS3700.  Total spindle count is
84 for this pool.  TSM DB and active log is stored on SSD (again hosted on
the V7000) and our TSM server is a P740 with 15 cores allocated to the TSM
LPAR and 125 GB of RAM.  We are in the process of migrating our TSM server
to the new-shiny Power 822 boxes, which will up our core-count to 18
Power8 cores and ~250GB of RAM (depending on how much is lost to VIO
servers)

How are you calculating the 2-300k IOPS?  What's the spindle count on the
Hitachi storage device?

We've been having some troubles with our database, which is ~2.3 TB
(though yours must be huge if you're managing 500 million objects).  Are
you doing offline db reorgs every six months or so?  We've found that
online reorgs are pretty much impossible, they fill the active log and
crash the server instance.

Matthew McGeary
Technical Specialist
PotashCorp - Saskatoon
306.933.8921



From:   Stefan Folkerts <stefan.folkerts AT GMAIL DOT COM>
To:     ADSM-L AT VM.MARIST DOT EDU
Date:   07/03/2014 05:13 AM
Subject:        Re: [ADSM-L] TSM 7.1 and dedup "chunking" issues
Sent by:        "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>



1.5TB seems like a very reasonable amount for these spec's, if the amount
of managed deduped data isn't above the 400TB you seem well within the
configuration maximums that IBM provides.



On Thu, Jul 3, 2014 at 12:02 AM, Bent Christensen <BVC AT cowi DOT dk> wrote:

> This server manages 200 clients, approx. 500.000.000 files occupying
> approx. 800 TB, a mixture of various databases, Exchange and files, all
> Windows clients. Not all client data end up in a dedup pool.
>
> Daily backup ingest to the dedup pool is 1.5 TB on average. We aim to
> receive backup data on an internal SAS array, backup to tape copypool
and
> then migrate to the dedup pool. The dedup pool storage is Hitachi AMS,
2000
> family with SATA disks, fiber attached, should be able to deliver at
least
> 2-300K IOPS in this configuration.
>
>  - Bent
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf 
> Of
> Stefan Folkerts
> Sent: Wednesday, July 02, 2014 2:13 PM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: [ADSM-L] TSM 7.1 and dedup "chunking" issues
>
> Also :
>
> >>32 cores, 256 GB RAM, DB and activelog on SSD.
>
> Wow, that's pretty serieus.
>
> Also, if I might ask, what is your daily backup/archive ingest, how much
> data do you manage and what type of disk (system/config) do you use for
> your filepool storage?
>
>
>
> On Wed, Jul 2, 2014 at 12:58 PM, Bent Christensen <BVC AT cowi DOT dk> wrote:
>
> > Hi all,
> >
> > I remember noticing that there were some dedup housekeeping (removal
> > of dereferenced chunks) issues with TSM Server 6.3.4.200 and that a
> > fix was released. We used 6.3.4.200 for a while as stepping stone on
> > our road from
> > 5.5 to 7.1 but without the fix.
> >
> > Now, on 7.1, I am seeing some stuff that makes me worry a bit -
> > initiated by a gut feeling that there are more data in my dedup pool
> > than there should be.
> >
> > SHOW DEDUPDELETEINFO shows that I have +30M chunks waiting in queue
> > and the number is increasing. It also shows that I right now have 8
> > active worker threads with a total of 5.8M  queued, but only approx.
> > 4000 chunks/hour get deleted.
> >
> > Any knowing if these numbers make sense?
> >
> > We use a full-blown TSM server on Windows, 32 cores, 256 GB RAM, DB
> > and activelog on SSD.
> >
> >  - Bent
> >
>