Perf issue with TSM

[megadub]

Hello,

I protect linux servers with TSM on Windows. But on one server, the performance are very poor. For example, I have 2 servers, serverA and serverB and during the night I can see:
ServerA:
Objects Backed Up : 4,500,000
Objects Updated: 5000
Bytes Moved: 10Gb
Elapsed Time: 7:30
% Compressed: 42%

ServerB:
Objects Backed Up : 15,000,000
Objects Updated: 25000
Bytes Moved: 6Gb
Elapsed Time: 3:00
% Compressed: 47%

It means that the second servers backed up more than 3 times more files in 2 times less long. And I cannot explain this difference. The sysadmin tell me that RSYNC is more efficient on ServerA than with TSM.

Could you tell me what I can check, try or measure to diagnose and solve this problem?

Thanks by advance for your assitance

PS : I forgot an important info, the backup consists only in flat files backup.

 

[moon-buddy]

First of all, are you comparing apples with apples?

Are the files on both servers about the same size? Are the servers the same: same CPU speed, same memory, same general hardware, same OS version and TSM version. Are the servers on the same LAN, and access rules the same for TSM access?

 

[megadub]

Very good remark... but I have no info about the client :'(

The network, TSM access and version are the same... for the rest, I'm going fishing the info

Regarding to the reports, the files seems to be bigger on the slower server.

 

[megadub]

BTW, are you surprised by these figures or it looks acceptable compared to what you know?

 

[moon-buddy]

BTW, are you surprised by these figures or it looks acceptable compared to what you know?

May or may not be normal - but I am inclined to think this is.

 

[DazRaz]

What is also of interest is how many files are are in total on each server. TSM is only backing up files which have changes and for the slower server it is possible that it is having to spend alot of time searching for changed files. Aside from the amount of processor on each server, the load on the servers when the backup is not running can be a factor. One server may be taking longer to compress the files.