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
>