Hi Neal,
we have the same problems with NETWARE and NT clients. It is not a question
of network-bandwith. The database on the server is to slow to handle such
requests. We tried increasing our DB-buffers, spread DB across multiple
disks (good performing disks). During such searches (especialy with -inact
-sub=yes), we see hundredthousends of DB-buffer requests. I deperatly hope
for a design change from IBM, like it took place from V2 to V3.
for a design change from IBM, like it took place from V2 to V3.
ADSM can handle the data on media(TAPEs, disks etc) very good, but a
present time it has tremendous problems in handling the big amount of
Information in his database, if it gets around 1 million of files per
client. And the number of files per client will increase.
I hope others in this forum are also talking to IBM about this point,
because I think it is the weakest point ADSM hast at present time. We
urgently need improvement in the database performance!! If not our clients
will spend days for searching the files and only minutes and hours for the
restore, and this they will not tolerate.
_________________________________________________
Kind Regards
Andreas Buser
Tel: ++41 61 285 73 21 Fax: ++41 61 285 70 98
Email: Andreas.Buser AT Basler DOT ch
Address:
Basler Versicherungsgesellschaft
Andreas Buser
Abt. Informatik
Aeschengraben 21
4002 Basel
Switzerland
Neal Adams
<neal AT SLAC DOT STA An: ADSM-L AT VM.MARIST
DOT EDU
NFORD.EDU> Kopie:
Gesendet von: Thema: NT restore
problem...suggestions?
"ADSM: Dist
Stor Manager"
<ADSM-L AT VM DOT MAR
IST.EDU>
18.09.99 01:10
Bitte
antworten an
"ADSM: Dist
Stor Manager"
I need some help regarding an NT client problem we're having and I don't
have
much experience with the NT client or NT.
We have an NT client with a RAID disk setup that we run an incremental
backup
on. Currently it's occupancy looks like this:
adsm> q occ rainmaker
Node Name Type Filespace Storage Number of
Space
Name Pool Name Files
Occupied
(MB)
------------------------ ---- ----------- ----------- ---------
----------
----------
BIGDAWG Bkup RAID1 BKP.DLT7000 952,533
BIGDAWG Bkup RAID1 BKP.DLT7000 952,533
27,168.39
BIGDAWG Bkup RAID1 CPY.DLT7000 952,533
27,168.39
BIGDAWG Bkup Backup OS BKP.DLT7000 137
1.02
BIGDAWG Bkup Backup OS CPY.DLT7000 137
1.02
Recently the folks that administer this machine had to restore some
inactive
files using the NT client (v3). It took forever just to get a list of files
to restore. My observation using the dsmc restore -pick for one
file was that it took 1hr 45 min to present a list to pick from. The ADSM
server
was relatively quiet at the time I was doing this. They've had to wait
hours
for responses from the GUI. The command line interface appears to work a
bit
better.
Is our problem because of the way the filespace backup is setup for RAID1?
Does restore look at every file (952K worth in this case)? Why is it so
slow?
Is there something we can do to our server or client configurations to
optimize restores? With Unix you can setup a virtualmountpoint which helps
when backing up and restoring large file systems. Is there a similar way to
setup an NT client?
Our server is an RS6000/F40 (1 cpu) running v2 with a db that looks like
this:
adsm> q db
Available Assigned Maximum Maximum Page Total Used %Util
Max.
Space Capacity Extension Reduction Size Usable Pages
%Util
(MB) (MB) (MB) (MB) (bytes) Pages
--------- -------- --------- --------- ------- --------- --------- -----
-----
-----
6,120 6,120 0 2,584 4,096 1,566,720 789,066 50.4
6,120 6,120 0 2,584 4,096 1,566,720 789,066 50.4
56.0
We are aware our server needs more horsepower and we're in the midst of
setting up an F50 with 4CPUs and much more memory.
Thanks for any information you can give..
========================================
Neal V. Adams
SLAC Computing Services -- Systems Group
phone: 650-926-2821
fax: 650-926-3329
email: neal AT slac.stanford DOT edu
========================================
|
