CPU utilization 100% Solved.

[hogmaster]

Background:
On one of several TSM servers running TSM 6.2 with dedup. The baclient administrators deleted several
large files 100 of gigabytes each from the backup, these files should not haven been sent to TSM at all.

After this the cpu have been att 100% at all times. We have applied the apropriate fixes but to no avail.
As a last resort I decided to run runsatat on all tabels in the db2 databse and then did a reorg of both
indexes and the backup table.
Now the cpu utilization is back in the normal range. So the probelm was that after deleting very large files that had been deduped the server was not able to bring order in the indexes.

/My 2 cents.

 

[JeanSeb]

Thanks for the info. I guess IBM warnings to NEVER use db2 tools to interact with the db2 db does not always apply

 

[hogmaster]

Yes, I did not do this lightly, but is sure payed off. Then again if this had been the old DB acting up then I do think we would have had to scrap the db and start again. So thanks to the tools available it was possible to solve the problem

 

[tkostrevc]

I would say, that was due to dedupdeletion threads, working on deletion of deduped chunks from the database. Try with setting DEDUPDELETIONTHREADS in your dsmserv.opt to a higher value like 8 and go to 6.2.2 when available.

 

[hogmaster]

Thanks for the information!
I would have liked to test this. A much better solution the have to mess around with DB2.

I guess that you think about the infomationa l message SQL0912N The maximum number of lock requests has been reached....
that we did not have. The deduped chunks was removed ok, the server was running backups alright, even dedup was running
Logging in and checking the status of the system was the real pain.

 

[tkostrevc]

Just one more word on a deduped chunks deletion, this is like another expiration processing, except that it's running constantly and benefits most from abundance of memory. So the rule would be, more is better (as usual... . To check status and backlog of deduped chunks deletion queue, you can use undocumented command SHOW DEDUPTHREAD. If backlog is getting huge (what is "huge" depends from system to system) or you notice any error states, then you have a problem. But thinking again on your initial problem, having indexes in good shape is of paramount importance, so you were right in doing runstats and reorg. Only one thing I'm curious, did you do offline reorg as you have said that indexes were reorged as well?

 

[hogmaster]

No offline just read access, the whole process was done in less than an hour.

 

[hogmaster]

IC69506: AUTOMATIC INDEX REORGS OF THE TIVOLI STORAGE MANAGER DATABASE DOES NOT OCCUR
This is the APAR fro this problem.
/regards Hogmaster