ADSM-L

Re: ADSM Performance

1996-04-29 07:43:44
Subject: Re: ADSM Performance
From: "Pittson, Timothy" <tpittson AT HIMAIL.HCC DOT COM>
Date: Mon, 29 Apr 1996 07:43:44 -0400
This seems to be slow for a PC but, as Jerry mentioned, would depend on
many factors (PC speed, operating system, network load, network card,
what TCPIP stack you are using,  number of hops to the ADSM server,
etc.)  Here's some number from some benchmarking I did back in January.
The network is 10 Mb Ethernet with the ADSM client and server on the
same segment.  For this test, no special tuning of the DSM.OPT file was
done....

PC - DX/2 66 Mhz with 32 MB RAM, EISA ethernet card
OS - OS/2 WARP with ADSM V2.1.02 client and compression enabled
Server- ADSM V2.1.02 server on an MVS/ESA 4.3 system
LAN - 10 Mb/sec ethernet via a 3172-3

Backup stats (entire PC) - 8166 files backed up, 448.2 MB, elapsed time
1 hour, 21 minutes (5.5 MB/sec)
Restore stats (one drive) - 5322 files restored, 214.3 MB, elapsed time
48 minutes (4.5 MB/sec)

On the ADSM server side of things, I've found that running many
incrementals concurrently, particularly for servers with slowincremental
on and with a 100K files + can slow down an ADSM server tremendously.
On our MVS system, ADSM runs at 90-95% CPU utilization for a good
portion of the night while incrementals are running (3090-500J) so it's
probably not so much ADSM as it is CPU speed and disk contention...  I
try to avoid running any background processes (migrate, reclamation,
expire processing, etc.) while the incremental backups are running;
otherwise things seem to grind to a halt.  I agree with Jerry that you
should have compression enabled on the client whenever possible although
it would be nice if something would be done about the problem ADSM has
with retransmitting an entire transaction when one of the compressed
files grows.  This is a BIG problem when you have you txngroupmax and
txnbytelimit parameters set higher than the defaults - (not to mention
having Netware 4.1 compression enabled although I think this problem was
addressed in the latest maintenance).

Tim Pittson
tpittson AT himail.hcc DOT com
>----------
>From:  Jerry Lawson[SMTP:jlawson AT ITTHARTFORD DOT COM]
>Sent:  Friday, April 26, 1996 3:29 PM
>To:    Multiple recipients of list ADSM-L
>Subject:       ADSM Performance
>
>---------------------------- Forwarded with Changes
>---------------------------
>From: INTERNET.OWNERAD at SNADGATE
>Date: 4/26/96 9:55AM
>To: Jerry Lawson at TISDMAIL
>*To: Multiple recipients of list ADSM-L at SNADGATE
>Subject: ADSM Performance
>------------------------------------------------------------------------
>-------
>
>John -
>
>Perhaps some others will also respond anf give you there opinion of
>whether
>this is slow or not, but I will throw my $.02 in anyway.   From what
>information you showed, I would say that this is a pretty typical time
>(at
>least in my shop), but there are many variables and things to consider
>that
>help to determine what is "slow".
>
>First, what is the configuration of the PC, Network, and server.  For
>example,
>how fast is the chip (Pentium 100MHz, etc.), and is it Ethernet, 4MB
>TR, 16MB
>TR, etc.  Is it Win95, Win 3.1, OS/2.  And where is the sever (VM, MVS,
>etc.)
>As with any performance issue, you need to know some things about the
>configuration to get an idea where to expect bottlenecks.
>
>Second, did you have compression turned on?  That will definately
>improve
>overall performance, at the expense of some contention on the client,
>if you
>are doing anything else.
>
>Also, consider that the test results indicate you were in essence doing
>a full
>backup.  Our experience has shown that the incrementals, while they
>show the
>same throughtput statistics, run in a very short period of time
>(typically 2-3
>minutes), so that many of them can run without impacting each other.
>This of
>course applies to desktop machines, Unix and LAN servers will obviously
>take
>longer.   Full backups need to be rolled in - that is you don't do
>large
>numbers of them at the same time.
>
>As for the tape cartridges, we also use 3480 with IDRC, and see the
>same
>thing.  We attribute this to the fact that what is being reported is
>the
>amount of compressed data that is fitted on the tape.  If you use
>ADSM's data
>compression (which I Advocate), IDRC cannot do much of a job
>compressing the
>data further.  Thus the ADSM report will look like IDRC is not working.
>Remember, and IDRC tape is the same length as a regular 3480; the data
>is
>written in the same format, but compressed by the control unit.  If
>it's
>compressed already, then it won't buy you much.
>
>BTW, here is a sample run from my daily backup - on a ThinkPad 750,
>with OS/2
>warp, 486-33Mhz, TCP/IP V3 over a 4Mb Token Ring network to an MVS
>version 2
>server.
>
>04/24/1996 07:13:46 Total number of objects inspected:   13,496
>04/24/1996 07:13:46 Total number of objects backed up:      109
>04/24/1996 07:13:46 Total number of objects updated:          0
>04/24/1996 07:13:46 Total number of objects rebound:          0
>04/24/1996 07:13:46 Total number of objects deleted:          1
>04/24/1996 07:13:46 Total number of objects failed:           0
>04/24/1996 07:13:46 Total number of bytes transferred:  1,828.8 KB
>04/24/1996 07:13:46 Data transfer time:                    3.33 sec
>04/24/1996 07:13:46 Data transfer rate:                  548.94 KB/sec
>04/24/1996 07:13:46 Average file size:                     27.3 KB
>04/24/1996 07:13:46 Compression percent reduction:        41.86%
>04/24/1996 07:13:46 Elapsed processing time:            0:02:58
>
>In looking at my log, it seems that performance has improved with
>version 2 of
>the server, and also with the latest client levels (this is V2.1.0.3)
>
>This has rambled on farther than I intended - hope it is of interest.
>
>Jerry Lawson
>jlawson AT itthartford DOT com
>
>
>
>________________________Forward Header________________________
>Author: INTERNET.OWNERAD
>Subject: ADSM Performance
>04-26-96 09:55 AM
>
>  I had installed ADSM several years ago, but there was not much
>interest in
>it at the time.  There have been several people requesting to use it
>now and
>I was wanting to get some statistics from other folks using ADSM.  I
>ran a
>sample job yesterday on my PC and got the following results:
>
>Files examined       10,644
>Files backed up       8,440
>Bytes transferred       615 MB
>Transfer rate           280 KB/sec
>Elapsed time        3:22:46
>
>This seems really slow.  If I have several people backing up at the
>same
>time, will this slow it even more?
>
>Also it asked for 4 cartridges.  We have 3480's with IDRC so I defined
>them
>as 3480XF to ADSM, but all they hold is approx. 200 MB.  Is this
>normal?
>
>I am thinking that I don't have something set quite right, but I would
>like
>to find out what other people are experiencing.
>
>Thanks in advance
>
>+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>+
>&  John Kaba                      & Internet   - CCJK AT FHSUVM.FHSU DOT EDU
>&
>&  Systems Software Analyst III   & SneakerNet - Tomanek Hall Rm. 147
>&
>&  Dept. of CTS                   & MaBell     - (913) 628-4489
>&
>&  Fort Hays State University     & Fax        - (913) 628-4096
>&
>+-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
>+
>
<Prev in Thread] Current Thread [Next in Thread>