TSM 6.3 Performance Problem

[FastBackTSMUK]

Hi,

I've installed a TSM V6.3 server in a test environment. It's all configured and working, but the performance of file, vm, and database backups is poor. XiV provides the storage under the covers, as well as the volumes for the database and logs. For SQL backups I'm only seeing 25GB/h, for file 10GB/h and for VM around 20GB/h. All data is backed up to a file device class with 100GB volumes. De-duplication is enabled.

I set-up TSM using the defaults. I suspect there is something odd with TSM since if I double the backup load e.g. 2 x client, the two clients achieve the same throughput as before.

Any ideas?

 

[moon-buddy]

Welcome to bleeding edge! Personally, I will wait until 6.3.2 or later!!

 

[FastBackTSMUK]

Welcome to bleeding edge! Personally, I will wait until 6.3.2 to later!!

So you would suspect there is something a miss with the 6.3.0.0 code?

 

[markus]

As far as i can say x.0.0 is never good for a production environment. I recently updatet our Testserver to 6.3.1.0 wich seems to work acceptable. Maybe you should run your test with this release.

 

[moon-buddy]

So you would suspect there is something a miss with the 6.3.0.0 code?

Normally - as Markus said - base releases are never 100% OK.

 

[rowl]

I know there is an issue with cpu utilization in the 6.3 release if you are running node replication. That was fixed in 6.3.1.

 

[rgg]

Have you captured any TSM performance tracing? I'd focus on the server disk read and write performance for some of those file volumes to see if it looks acceptable.

By the way, is client-side dedup enabled, or server, or both?

 

[Castaway]

As a storage administrator as well as TSM administrator, I was told XIV's (gen I & II anyway) were not good used as a platform for databases because they do not cache writes and, with the additional load of a true DB2 database, you may be seeing that, but as IBM says, your mileage may vary. If you have it under SVC, do you have a DS8K or even a DS4K to test it with? just mirror the drives to another managed disk group on one of those cached platforms, break the mirror for copy 0 (or whichever one the XIV is) and voila, it exists on a different platform.