Where do you have your swap space/paging file? Could be your C: disk is
to busy?
Orville L. Lantto
Datatrend Technologies, Inc.
121 Cheshire Lane #700
Minnetonka, MN 55305
"Ripley, Bev" <[EMAIL PROTECTED]>
Sent by: "ADSM: Dist Stor Manager" <[EMAIL PROTECTED]>
10/04/01 08:36 AM
Please respond to "ADSM: Dist Stor Manager"
To: [EMAIL PROTECTED]
cc:
Subject: Re: NT client restore C drive
Sorry - I forgot to mention that our cache hit is 98.23 so that looks ok.
And, agreed, the command line is slightly faster but not dramatically
different. Where we see the big difference is when we boot the client
from
an alternate partition, simulating the destruction of that client. Our
first testing had this alternate partition with a different node name than
the original which caused us to have to specify the path to restore a
disk,
directory, or file. We got very slow performance with this. Next we
changed this alternate partition to have the same node name as the
original
client so we could then do a restore without being forced to specify the
path. Unfortunately, this had the same result. So at this point we have
to
believe the problem is something to do with running the client from an
alternate partition (and, therefore, not running from the C drive). I
have
seen statements that the client should be running from the C drive, but if
you lose the client entirely, how do you restore enough of the client to
get
back to the C drive to then complete the rest of the restores?
No changes are being made to the file system types, either. At this time
we
are dealing with a test NT box, deleting the data or formatting disks and
trying to recover it to exactly the same hardware and software.
Examples: restoring a directory of 178 MB of data, 2925 objects took 2:35
minutes when restored from the original client, while it took 1 hour and
10
minutes when the restore was initiated from the alternate partition.
Restoring the D drive, 195 MB, 4955 objects took 4:25 minutes from the
original client, while it took 1 hour and 41 minutes when initiated from
the
alternate partition.
-----Original Message-----
From: Christo Heu�r [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 04, 2001 8:49 AM
To: [EMAIL PROTECTED]
Subject: Re: Re: NT client restore C drive
That does sound a bit funny.
>From the difference in performance between the GUI and the
cmd line - the cmd line is faster.
As far as I've seen the restore command does not behave
differently when specifying a path other than the original.
Have you looked at the cache hit percentage. When you are
restoring a lot of files this makes quite a difference in the
overall picture.
As a matter of interest - why are you restoring to a different path
than the original path the data was backed up on?
Something you could look at is the type of file system your new
NT system has - was it using NTFS and now fat or the other
way around?
Let me know as you progress.
Regards
Christo Heuer
We are running on what we call a baby mainframe - Multiprise 3000 -
utilizing the internal adapter. Some basic ftp testing does show us that
this is not exactly stellar performance on throughput. But our basic
issue
here is that we are getting some very different performance levels when
dealing with restore commands. Perhaps a further clarification from our
ongoing testing would be to say that we are seeing very dramatically
different restore results from entering restore commands either through
the
gui or command line when we have booted from an alternate partition on the
NT client. It is dramatically worse performance from the alternate
partition. But this is what we would anticipate having to do if we lost
the
client machine entirely. And so far, this is really unacceptable results.
There must be something very different in the processing of the restore
when
a path is specified for the restore as opposed to choosing the "put it
back
where it came from" option. Any suggestions for us?
Thanks for any help you can offer.
-----Original Message-----
From: Christo Heu�r [mailto:[EMAIL PROTECTED]]
Sent: Thursday, October 04, 2001 7:26 AM
To: [EMAIL PROTECTED]
Subject: Re: Re: NT client restore C drive
Hi Bev,
You said you are running 10/100 Ethernet network - I presume
this is on the NT machine. What is the interface into the TSM server
like (What networking hardware are you using attaching your OS/390
system to the rest of the IP network?)
As a start - do a ftp from your client on NT to the OS/390 box. This
will eliminate any TSM related tuning that you can do.
Even on a default config running via a 3172 controller(16M T/Ring),
we get better performance than you are getting. (About four times
better than what you are seeing on your D drive restore....)
The FTP will indicate if the network can pump the data fast enough.
The second thing is look at your cache hit statistics on the server via
the q db f=d command - your cache hit must be above 98% - if not
you are experiencing memory problems on the TSM server side of
things - this will definately affect the speed at which you are restoring
files -
especially if you move a lot of small files.
Let me know how it goes.
Regards
Christo Heuer
ABSA Bank
Johannesburg
SOUTH AFRICA
> Thanks for the suggestion but there are no tapes involved. This is a
test
> environment still and we are only going to dasd on the mainframe server.
>
> On a bare bones restore of a Windows NT client's C drive, we are getting
> very poor throughput times. For example, it is taking an hour and a
half
to
> restore 200 MB. Restoring the D drive is much better - 4 minutes for 50
MB.
> We have release 4.1, a 10/100 Ethernet network, OS/390 TSM server, and
we
> are booting off an alternate partition on the NT client to restore the C
> drive.
> Why would we have such a discrepancy in restore times between the 2
drives?
> And is this average performance? We have much larger servers coming up
in
> our plans and this is not an acceptable timeframe for restores.
> TIA
>
>
----------------------------------------------------------------------------
> --
