We have a similar environment (+1 million files in active filespaces). We
have been conducting regular disaster recovery tests and have also seen the
performance problems that you address.
One of our problems that we discovered, was the fact that although data had
been backing up with V3 client and server for sometime, some data was still
active that had been backed up using V2. Apparently, if there is any active
V2 data, a V3 restore will behave like a V2 restore (Grab breakfast, lunch,
and dinner while you wait for the client to build the restore list). Can
anyone at ADSM Development confirm this?
Another problem we encountered was with multistreaming the restore. We had
been using an uncollocated storagepool. When we began multiple restore
sessions, it was not long before there was tape contention. You have the
same issue when you use collocation at the node level, therefore we found
that collocation at the filespace level is our only viable alternative.
Hope that this helps,
Christopher Bushman
NT Technical Services -200 AMP Drive
AMP Inc.
M.S. 194-009
P.O. Box 3608
Harrisburg, PA 17105-3608
Email: cbushman AT amp DOT com
Phone: (717) 810-2589
Fax: (717) 810-2236
> -----Original Message-----
> From: Trevor Foley [SMTP:Trevor.Foley AT BANKERSTRUST.COM DOT AU]
> Sent: Tuesday, November 03, 1998 2:39 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Performance problems restoring to WindowsNT servers
>
> Hi,
>
> We are getting ready for our first disaster recovery test this weekend
> using
> ADSM as our exclusive backup utility. We have been doing some test
> restores,
> and things are looking pretty gloomy. Our major focus is WindowsNT, but
> other platforms seem to be having problems also.
>
> The systems that we are testing have very large numbers (some in excess of
> 1
> million) of active backup files on a single filespace, most of which are
> very small. So we expect some amount of delay before data starts moving on
> a
> restore. But we are seeing extremely poor performance. One of the test
> restores, for an entire volume, resulted in 1.3 files per second being
> restore. When you talk about 1 million files, that is a long time. Another
> test, this time for only one directory tree, restored 143 files in 38
> minutes; much worse. This second restore we see very long pause times with
> no noticable activity; no volume mounts, the session in 'Run' state, and
> the
> GUI (yes, I know that the the command line may give better performance but
> I
> tried the command line and saw no noticable difference) showing the same
> filename being processed and the status bar showing no data transferred
> for
> that file. I then did a contrived test by backing up a set of files to a
> disk pool, and then restoring them. This resulted in 11 files per second
> being restored, which is getting close to acceptable.
>
> So, I guess what I am after are some suggestions as to what I could try to
> improve things, and some idea of what sort of performance others are
> experiencing. Note that the restores are coming from systems that have
> been
> ADSM clients for many months and therefore have data spread across
> multiple
> (the worst that I have seen is 9) collacted volumes.
>
> Our environment is:
>
> * ADSM Server 3.1.2.0 on AIX using an R50 server and 3590 drives in
> a
> 3494 library
> * WindowsNT 4.0 SP3 clients using 3.1.0.3
>
>
> regards,
>
> Trevor
|
