extentupdates never reducing

gernthefish

ADSM.ORG Member
Joined
Mar 3, 2005
Messages
139
Reaction score
0
Points
0
PREDATAR Control23

We use cloud container pools and recently noticed our DB and DB backups getting larger while data stg space and # of files staying about the same. We soon discovered our # of extentupdates growing, and never shrinking as they should be. Ideally, they should get processed frequently and reduce down to 0. Ours are over 200 million and growing daily. These records start to process if we restart TSM, but it really hits the system hard and eventually just stops processing extents for some reason. I know CHUNKDELETIONDELAY can be changed to slow down building the list of eligible extents, but I don't think this will help to control the actual deletion process itself. Any thoughts on this? Is there a way to control the # of threads used to process these extent deletions?
 
PREDATAR Control23

Nevermind, that APAR is for directory container pool, you have a cloud. However, you could still benefit at 8.1.9.000 to ensure you have all the fixes to known issues.
 
PREDATAR Control23

That's a good suggestion, Marclant. We are currently on v8.1.6.200 which is supposed to have a fix for this (IT28470 - https://www-01.ibm.com/support/docview.wss?uid=swg1IT28470). But I agree, it would probably be a good idea to upgrade.

I was also wondering if lowering DEDUPEDELETIONTHREADS might help. We have 8 currently (I believe this is default). The idea would be to allow extent deletions to proceed, but more slowly to avoid performance impact. I'm having a tough time finding good doc on this option. Any idea if this would be beneficial?
 
PREDATAR Control23

I was also wondering if lowering DEDUPEDELETIONTHREADS might help.
Lowering the number of threads would be counter productive if you have a large number of extents to delete. Reducing that the number of threads will take even longer to delete to the point that it may not keep up with the daily workload.
 
PREDATAR Control23

Well, normally it never runs at all unless I restart TSM. Then it starts to delete, but it grabs all the system resources and backups grind to a halt. The deletion eventually stops after 12 hours or so for some reason, and everything starts running normally again. Running the deletes just kills the server, so we really don't want it to run for long durations. But since we're so far behind, it runs a long time and it has to stop on its own. I was just thinking we could throttle it down a little so it wouldn't slow down normal operations.
 
PREDATAR Control23

That doesn't sound right. APAR IT28470 may still be at play, even if it doesn't mention cloud containers, the symptoms are quite similar.
 
Top