... OK, I shouldn't be laughing but I guess you missed a few of my
messages in the past... I HAVE TONS OF NOVELL 4.1 SERVERS WITH 60GB
(120GB but mirrored) Ha, I'm smoke'n you on restore times... at first
I was seeing 500MB/hr... Just think if a fire took out about 6 of
these babies....Hmmmm 6 times 60 is 360 GB or 368640 MB divided by the
500MB/hr, I could be back up and running in 737.28 hours (excluding
tape mount time) heck why don't we just call it ONE MONTH !
Ok, really now... NOVELL+ADSM tricks for faster backup/recoveries :
1) processorutilization in the novell option file... 1-infinity,
default is 1, try 20
2) run multiple, concurrent sessions... you can do this by having your
adsm server schedule an event that is a command and make that
command something like INCR.NCF and inside that put statements like
LOAD DSMC INCREMENTAL SYS:
LOAD DSMC INCREMENTAL APPS:
and on BUT !!!!! this will probably end with all data on one (1)
tape SOOOO (but it will cost you for extra licenses) do an
additional trick, TURN ON COLLOCATION and modify the stmnts thus:
LOAD DSMC -NODE=nodenameSYS INCREMENTAL SYS:
LOAD DSMC -NODE=nodenameAPPS INCREMENTAL APPS:
LOAD DSMC -NODE=nodenameDATA INCREMENTAL DATA:
now all the data for each logical volume resides on seperate tape pool
volumes SO YOU CAN RUN MULTIPLE, CONCURRENT RESTORES ! ! !
If you could run it across FDDI you should do so...
AND FOR ANY WHO MISSED IT EARLIER, SET THE FDDI PACKET SIZE TO 4202 IF
YOU ARE EXPERIENCING INITIAL HANDSHAKES FOLLOWED BY TIMEOUT'S WHEN
SCHEDULED EVENTS RUN AGAINST NOVELL CLIENTS, your server is probably
sending packets larger than novell is set to handle...
3) MAX out parms like the TXN's for clients & server and it shouldn't
hurt if you have an ADSM6000 server with 2.1.0.9 to max out the
MAXMOVEblah parameters...
4) Back on the server... make sure the DB & LOG are on seperate
physical volumes ! Novell servers, well servers in general, seem to
contain billions & billions of 0.5KB files and the DB&LOG activity
will kill you... if you can split the DB up over different physical
volumes I would do that also... (don't have specifics but just
knowing that the DB holds EVERYTHING, not only bkup/arc files and
their locations but also the activity log info, scheduled event
info, etc. one could assume they stand a good chance at reducing
I/O wait time [against db volumes] by splitting it up across phy
volumes...
That's about all I can think of currently... Hope it helps...
Oh, 'bout 6-6.5GB with 5 concurrent sessions over FDDI was/is about
our best so far... I wish you the best of luck in beating that, if you
do... please launch some tips back my way....
later
Dwight
______________________________ Reply Separator _________________________________
Subject: ADSM performance
Author: ADSM-L at unix,mime/DD.RFC-822=ADSM-L AT VM.MARIST DOT EDU
Date: 9/24/96 10:49 AM
Hello,
We are running ADSM on an 9672-r32 mainframe with MVS/ESA v4.3 using
a 3172 control unit with an ESCON adapter. We are backing up mainly Novell
v3.11 servers on either T/R 16 Mbps or ETHERNET 10 Mbps, using two 3494
tape drives. The problem we are having concerns extremely slow
backup/restore times on the larger servers (15-20Gb). We tested a restore
of 1.5Gb of data on a server with a 486/66 cpu and it took 4 hours to
complete. What concerns us is if we had to do a restore of an entire 15Gb
server. It appears this would take an enormous amount of time. We were
wondering if there was any way we could tweak either ADSM, Novell or MVS
to improve performance? Here's the route our restores take:
3494 tape => ESCON => 3172 => T/R LAN => Server @ 700kb/sec transfer rate
|
|
ROUTER
|
ETHERNET LAN => Server @ 900kb/sec transfer rate
Any suggestions on how to improve our performance would be appreciated.
Mark Mazur
|
