Woo hoo!
That's great news.
Will open a ticket and escalate.
Also looking at client-side dedup, but I have to do some architectural
planning, as all the data is coming from one client, the TSM VE data mover,
which is a vm.
Re client-side dedup, do you know if there is any cooperation between the
client-side dedup and deduprequiresbackup on the server end?
I have assumed that the client-side dedup would not offer that protection.
W
-----Original Message-----
From: Sergio O. Fuentes [mailto:sfuentes AT umd DOT edu]
Sent: Friday, December 20, 2013 10:39 AM
To: ADSM: Dist Stor Manager
Cc: Prather, Wanda
Subject: Re: [ADSM-L] Deduplication "number of chunks waiting in queue"
continues to rise?
Wanda,
In trying to troubleshoot an unrelated performance PMR, IBM provided me with an
e-fix for the dedupdel bottleneck that it sounds like you're experiencing.
They obviously will want to do their due-diligence on whether or not this efix
will help solve your problems, but it has proved very useful in my environment.
They even had to compile a solaris e-fix for me, cause it seems like I'm the
only one running TSM on Solaris. The e-fix was very simple to install.
What you don't want to do is go to 6.3.4.2, unless they tell you to because the
e-fix is for that level (207). Don't run on 6.3.4.2 for even a minute. Only
install it to get to the e-fix level.
Dedupdel gets populated by anything that deletes data from the stgpool, I.e.
move data, expire inv, delete filespace, move nodedata, etc.
We run client-side dedupe (which works pretty well, except when you run into
performance issues on the server) and so our identifies don't run very long, if
at all. It might save you time to run client-side dedupe.
BTW, when I finally got this efix and TSM was able to catch-up with the deletes
and reclaims as it needed to, I got some serious space space back in my TDP
Dedup pool. It went from 90% util to 60% util (with about 10TB of total
capacity). What finally really got me before the fix was that I had to delete
a bunch of old TDP MSSQL filespaces and it just took forever for TSM to catch
up. I have a few deletes to do now, and I'm a bit wary because I don't want to
hose my server again.
I would escalate with IBM support and have them supply you the e-fix.
6.3.4.3 I don't think is slated for release any time within the next few days,
and you'll just be struggling to deal with the performance issue.
HTH,
Sergio
On 12/19/13 11:35 PM, "Prather, Wanda" <Wanda.Prather AT ICFI DOT COM> wrote:
>TSM 6.3.4.00 on Win2K8
>Perhaps some of you that have dealt with the dedup "chunking" problem
>can enlighten me.
>TSM/VE backs up to a dedup file pool, about 4 TB of changed blocks per
>day
>
>I currently have more than 2 TB (yep, terabytes) of volumes in that
>file pool that will not reclaim.
>We were told by support that when you do:
>
>SHOW DEDUPDELETEINFO
>That the "number of chunks waiting in queue" has to go to zero for
>those volumes to reclaim.
>
>(I know that there is a fix at 6.3.4.200 to improve the chunking
>process, but that has been APARed, and waiting on 6.3.4.300.)
>
>I have shut down IDENTIFY DUPLICATES and reclamation for this pool.
>There are no clients writing into the pool, we have redirected backups
>to a non-dedup pool for now to try and get this cleared up.
>There is no client-side dedup here, only server side.
>I've also set deduprequiresbackup to NO for now, although I hate doing
>that, to make sure that doesn't' interfere with the reclaim process.
>
>But SHOW DEDUPDELETEINFO shows that the "number of chunks waiting in
>queue" is *still* increasing.
>So, WHAT is putting stuff on that dedup delete queue?
>And how do I ever gain ground?
>
>W
>
>
>
>**Please note new office phone:
>Wanda Prather | Senior Technical Specialist | Wanda.Prather AT icfi DOT com
>| www.icfi.com
>ICF International | 443-718-4900 (o)
|
