ADSM-L

Re: Problems with Windows Cluster.

2003-01-10 15:30:21
Subject: Re: Problems with Windows Cluster.
From: Andrew Raibeck <storman AT US.IBM DOT COM>
To: ADSM-L AT VM.MARIST DOT EDU
Date: Fri, 10 Jan 2003 13:29:44 -0700
What exactly about TSM is taking so long? Is it the amount of time it
takes to move the data? Is it the amount of time it takes to traverse the
file system? Is it the amount of time it takes to query the TSM server for
existing inventory, before it actually starts looking for changed files?
If you do a QUERY SESSION on the server while the backup is running, what
do you see? Run QUERY SESSION periodically (say, once every 5 minutes) for
an hour or so... is there a pattern? That is, do you see length mount wait
times, receive wait, send wait, or run?

You might first verify that the problem is not in how long it takes to
move data. Try doing a selective backup of a single large file (say, 200
MB). Does the file seem to back up in a reasonable time frame? If not,
then you need to look at performance (disk I/O on the client, network
performance, TSM server performance, etc.).

If the file backs up reasonably fast, then maybe it's just the size (in
terms of number of files) of your file system. This can incur lots of wait
time in a couple of key places: (1) while the client queries the server
for the current backup inventory, and (2) while the client traverses the
file system.

If it looks like the number of files on the file system is the issue, then
if relatively few files change on a daily basis (so TSM spends most of its
time traversing the file system but not backing up many files), consider
implementing the TSM journal backup service.

If the number of files on the file system is the issue but lots of files
change daily, then you might consider doing "incremental-by-date" backups
on a daily basis, and full incrementals on a weekly (or other periodic)
basis. If you are unfamiliar with incremental by date concept, please
refer to the client manual which discusses this.

The above is not meant to be a definitive list of all available options;
others on the list with more practical experience than I may offer some
good advice. There may be some additional performance tuning you can do
with your network, client and server operating systems, and client and
server options files.

Regards,

Andy

Andy Raibeck
IBM Software Group
Tivoli Storage Manager Client Development
Internal Notes e-mail: Andrew Raibeck/Tucson/IBM@IBMUS
Internet e-mail: storman AT us.eyebm DOT com (change eye to i to reply)

The only dumb question is the one that goes unasked.
The command line is your friend.
"Good enough" is the enemy of excellence.




Jorge Martins <jgmpereira AT IBEST.COM DOT BR>
Sent by: "ADSM: Dist Stor Manager" <ADSM-L AT VM.MARIST DOT EDU>
01/10/2003 12:41
Please respond to "ADSM: Dist Stor Manager"


        To:     ADSM-L AT VM.MARIST DOT EDU
        cc:
        Subject:        Problems with Windows Cluster.



Hello folks !!!

I have a problem with a Windows 2000 cluster. The TSM is taking a long
time to do the backup. it4s a long time processing the files locally (I
look for problems in CPU utilization, Processor utilization, and so
on...). there is lots of files locally (aproximately 1.000.000 files, it4s
a file server).

the network traffic rate is ok (between 6 and 15 MB)...the Machine is a
Intel with 2 GB RAM, 180 GB HD, 4 GB virtual memory.

I have tried a script (or several scripts), describing the list of
files...I tried several schedules (with several scripts)...and the time
so, so..........long - aproximately 40 hours...I put in dsm.opt the
resourceutilization for 6 (trying open several sessions to backup go
on...).

I don4t know anymore...

Please, anyone can help me ??


hugs

Jorge Martins
Service IT Solutions
www.service.com.br - RS/Brazil



Icon - Internet gratis, MP3, Vmdeo, radio, e-mail e informagco.
Pega ja o seu em www.ibest.com.br/icon/mail1.html. I gratis!

<Prev in Thread] Current Thread [Next in Thread>