Does this performance look ok?

2003-02-21 Thread Farren Minns
Good afternoon all

I'm running TSM 4.2.2.12 on a Solaris 7 Machine and am in the never ending
search for ways to imrpove / check performance of our server as we are
getting some massive (and I mean huge) variations in backup and restore
times from machine to machine.

Our Solaris box is a 1CPU 400Mhz with 1GB Ram.
Database = 8500Mb (81% utilised) on a A1000 Storage Array (RAID5)
Buffpoolcache is 64Mb

Right now I'm running expiration on the database. Nothing else is running
at all. I have printed the output of the vmstat command and was wondering
if it looks acceptable. The output is as follows :-

procs     memory            page            disk          faults      cpu
 r b w   swap  free  re  mf pi po fr de sr m0 m1 m2 m1   in   sy   cs us sy
id
 1 0 0   1560   768   0   5 131 0 300 0 173 0  0  0  0  174   83   98  3 26
70
 3 1 0 1702768 31416  0   1 432 0 400 0 68  0  0  0  0  625  711  625  8 81
11
 1 1 0 1702768 31312  0   0 325 0 416 0 68  0  0  0  0  667 1634  602 24 68
8
 1 0 0 1702768 31416  0   0 224 0 216 0 33  0  0  0  0  636  503  507  4 79
17
 0 0 0 1702768 31448  0   0 154 0 165 0 43  0  0  0  0  565  460  433  3 88
10
 1 1 0 1702808 31440  0  23 280 0 224 0 35  0  0  0  0  585  571  504  7 79
14
 3 0 0 1702896 31376  0   0 253 0 280 0 43  0  0  0  0  601  431  422  1 84
15
 0 0 0 1702896 31456  0   0 141 0 152 0 23  0  0  0  0  549  439  420  4 88
8
 2 1 0 1702896 31424  0   0 184 0 213 0 32  0  0  0  0  600  438  422  3 83
14
 2 0 0 1702896 31448  0   0 184 0 197 0 29  0  0  0  0  635  488  482  3 84
12
 2 0 0 1702896 31424  0   0 210 0 218 0 44  0  0  0  0  624  468  447  3 77
19
 3 0 0 1702896 31408  0   0 200 0 240 0 43  0  0  0  0  625  435  450  3 79
18
 2 0 0 1702896 31232  0   0 376 0 384 0 56  0  0  0  0  645  464  459  4 76
19
 1 0 0 1702896 31440  0   0 264 0 272 0 54  0  0  0  0  647  523  506  5 82
13
 2 0 0 1702896 31448  0   0 173 0 162 0 27  0  0  0  0  567  519  498  5 84
11
 1 0 0 1702896 31448  0   0 256 0 266 0 48  0  0  0  0  605  430  412  1 84
15
 0 0 0 1702896 31440  0   0 162 0 162 0 23  0  0  0  0  520  379  385  1 84
15

The cache hit ratio is running at 98.14 at present.

Many thanks

Farren Minns - John Wiley & Sons Ltd




Re: Does this performance look ok?

2003-02-21 Thread Richard Sims
>I'm running TSM 4.2.2.12 on a Solaris 7 Machine and am in the never
>ending search for ways to imrpove / check performance of our server as
>we are getting some massive (and I mean huge) variations in backup and
>restore times from machine to machine.

A frequently posted cause is the use of Ethernet Autonegotiation or
conflicting hard specification of Ethernet characteristics in the host
vs. the router/switch.  Be sure to check that.  See ADSM-L archives.

  Richard Sims, BU



Re: Does this performance look ok?

2003-02-21 Thread Dirk Billerbeck
Hi Farren,

I'm not familiar with the vmstat command and Solaris but this is what I
have learned during the last years as a TSM consultant:

- Use as much and as fast CPUs as possible for the TSM server. As every
database-based application TSM is CPU-depending. I've seen very great
performance differences between different TSM servers. At one time we
upgraded a single CPU Windows TSM Box to a dual processor machine and the
performance of the expiration process rose from 200 examined objects per
second (EOPS) to more than 3.000 EOPS... Or the database backup process:
I've seen systems backing up 30.000 pages per minute and other TSM servers
accomplish over 60.000 pages (both using IBM LTO Ultrium drives). CPU power
also affects the client performance because client and server have to
search for eligible files to back up and the larger the number of files on
a client or the higher the number of versions the longer does it take to
back up the client.

- Try to optimize your cache hit ratio at a level > 99%. The new
SELFTUNEBUFPOOLSIZE option is very helpful for this task...

- Use raw partitions rather than ufs or vxfs filesystems for the db,
recovery log and disk storage pool volumes (if possible).

- Look at the network settings for the affected clients. E.g. auto-sensing
is known to cause problems for certain network adapter/switch combinations
or different settings for full-/halfduplex. Or try an ftp transfer from the
client to the TSM server and vice versa to see if the network is the
bottleneck (Once one of our customers complained about the backup
performance but he had forgotten that the leasing contract of his DNS
server had expired and the system had been removed. I was just wondering
that TSM was backing up data at all...).

- Look at the memory consumption on the clients and the server during the
backup. Tuning the memory subsystem can solve many performance issues...

I don't know what type of clients you back up, what kind of hardware they
are running on or which type of data they have but performance tuning can
be a very difficult task. And you have to look at each client individually.


Mit freundlichen Grüßen,
Met vriendelijke groeten,
With best regards,
Bien amicalement,

CU/2,
Dirk Billerbeck


Dirk Billerbeck
CC CompuNet AG & Co. oHG
Enterprise Computing Solutions
Am Jaegersberg 20, 24161 Altenholz (Kiel), Germany
Phone: +49 (0) 431 / 3609 - 117, Fax: +49 (0) 431 / 3609 - 190,
Internet: [EMAIL PROTECTED]


This email is confidential. If you are not the intended recipient,
you must not disclose or use the information contained in it.
If you have received this mail in error, please tell us
immediately by return email and delete the document.