Schedule Randomization and CPU Load

[Andrew21210]

Can anyone tell me if there is any relationship between schedule randomization percentage and CPU load (on the server)? I see some conflicting info on the net about this.

 

[marclant]

There is a relation.

If all the nodes associated with a schedule were to start at exactly the same time for an incremental backup, the first thing the clients will do is send a query to the TSM Server to get the list of objects previously backed. The server has to run that query for each. The larger the number of simultaneous queries, the higher the CPU utilization will be.

Now, depending on the number of nodes associated to that schedule and the size of them, and also depending on the size of your TSM Server, you may or may not notice it.

 

[Andrew21210]

We're set for the out of the box default (25). We're looking for ways to reduce CPU load on the server. Would increasing this randomization percentage to, say, 40 buy us anything?

 

[moon-buddy]

We're set for the out of the box default (25). We're looking for ways to reduce CPU load on the server. Would increasing this randomization percentage to, say, 40 buy us anything?

I have set the value at 50 and a duration of 2 hours - works best for me.

 

[marclant]

We're set for the out of the box default (25). We're looking for ways to reduce CPU load on the server. Would increasing this randomization percentage to, say, 40 buy us anything?

The usual answer applies: "It depends". Performance is part art and part science. You could try changing the values to see if it makes a difference.

Also, make sure there are no housekeeping processes running at the same time as the backup, because those can be CPU intensive too.

Reorgs should also run when the server is idle (or least busy).

The box could be undersized too, you may need more CPU, depends on your config. Sometimes, the workload you have is the workload you need to support, so in a case like this, you need the hardware to support the workload rather than to try to find a workload that the hardware can handle.

 

[marclant]

Are you using dedup? If so, did you see if your config matches the blueprint: https://ibm.biz/BdHFmv

 

[Phil_02GT]

One suggestion is to check if you have other TSM processes running during the backup window. The most power hungry processes are usually the "expire inventory" and "identify duplicate".

Also if your TSM server does not meet the requirements I suggest you move the Operation Center to another server if you have it installed on your TSM server. A VM is good enough for this.
Depending on the platform, check if you have an antivirus that scans TSM related files (database, storage pool, etc) and exclude them if you can, Windows updates schedule, etc
Review the specs of your server and the type of storage pool (file, disk, container), dedup or no dedup, etc, number or clients and see if it meets the requirements.