ADSM-L

Re: ADSM Server on MVS

1999-03-03 10:35:06
Subject: Re: ADSM Server on MVS
From: "Richard C. Dempsey" <dempsey AT KODAK DOT COM>
Date: Wed, 3 Mar 1999 10:35:06 -0500
Just as a point of comparison, on our Sun Solaris systems, we've
seen aggregate throughput of about 13 GB/hour when backing up some
of our DB systems.

The network is 100 MB/s switched ethernet.  COMMmethod is TCPIP

The ADSM 3.1.2.0 server is a dedicated Sun Ultra 2, 168 MHz clock,
512 MB memory.  We use a 3570-B11 library, and backup direct to tape.

The client in question is a Sun E450, 1 GB RAM.  In a DB cold backup,
we saw these results:

>Total number of objects inspected:      134
>Total number of objects backed up:       73
>Total number of objects updated:          0
>Total number of objects rebound:          0
>Total number of objects deleted:          2
>Total number of objects failed:           0
>Total number of bytes transferred:    24.57 GB
>Data transfer time:                5,993.15 sec
>Network data transfer rate:        4,299.86 KB/sec
>Aggregate data transfer rate:      3,792.22 KB/sec
>Objects compressed by:                    0%
>Elapsed processing time:           01:53:15

If we had the luxury of a 25 GB disk storage pool to receive
the data, instead of going to direct to tape, we could improve
these times somewhat.

One should be wary that overall backup throughput will depend
on the number of objects to examine on the client.  The client
will keep the server waiting while the client goes through its
file system.  This is no fault of the server or the network.
Recalling the discussion on Lotus Notes backup, there are also
circumstances where a fair amount of bandwidth can be consumed
just in the server telling the client about the objects that
are stored on the server.

This DB example has low overhead because there are so few files.
And, the servers in question are on the same subnet (the same
ethernet switch, even), so there are no routers to get in the way.
Nonetheless, it would appear that a reasonably fat Sun E250 with
a good sized tape library would be able to handle a lot of clients
without breaking a sweat, without upsetting the glass house folks,
and without killing your budget.

YMMV  (:-o),
Rich


At 08:12 AM 3/3/99 -0500, you wrote:
>Wow!! This subject has generated a lot of comments.  Sounds like we've all
>been lulled into a state of acceptance on the network performance for the
>MVS server - until someone brought the subject up again .... (was that me
>?? - or no, I guess it was Alan).  Just to respond to a few
>questions/comments:
>
>     - Yes, we really are only getting 1.5 - 2 GB/hr on the OSA
>     - Our network configuration for inbound traffic is through an ATM
>router,
>       to the ATM switch, the ATM cloud (155 MB/s), and to the OSA.  Again,
>ALL
>       inbound traffic comes through this route.  I'm not really a network
>guru,
>       so I can't get much more specific than that.
>     - We are running OS/390 2.4, TCP/IP 3.2 (not the rewritten version)
>soon to
>        be 3.4 (June), which I understand should help the situation.  We do
>have
>        a socket reserved for ADSM use only.
>     - We back up over 300 clients per night, about 75 GB transferred
>     - We force compression on at the client
>     - We are running 3.1.2.14 of the server
>     - We ARE using the MPTHREADING set to YES (not ON). This has
>definitely given
>        us performance increases in CPU utilization.
>
>Also - Alan, you asked about the processor utilization on the clients.  I'm
>afraid I have to admit that I have no idea.  We have, however, always run
>scheduled backups on off-hours, and have never really heard any complaints.
>
>                         Ginny
>
>
>
>
>
>Date:    Tue, 2 Mar 1999 08:10:54 PST
>From:    Sam Sheppard <SHS AT SDDPC.SANNET DOT GOV>
>Subject: Re: MVS ADSM Server
>
>
>
>---------------------------- Top of message ----------------------------
>>>--> 03-02-99  08:02  S.SHEPPARD     (SHS)    Re: MVS ADSM Server
>I would be curious to know what levels of MVS or OS/390 you are running.
>We are getting 2-3+G/hr over FDDI when running OS/390 2.5 (the rewritten
>TCPIP stack). If you are running anything below this, your performance
>will not be that good.  We backup 200+ clients a night with 60-70G
>transferred and are not seeing any big problems.
>Sam Sheppard
>San Diego Data Processing Corp.
>shs AT sddpc.sannet DOT gov
>
>
>Date:    Tue, 2 Mar 1999 16:02:22 +0100
>From:    Roger Hohmann <Roger_Hohmann AT WESTLB DOT DE>
>Subject: Re: ADSM Server on MVS
>MIME-Version: 1.0
>Content-Type: text/plain; charset="us-ascii"
>Content-Transfer-Encoding: 7bit
>
>
>
>As far as I know, the maximum throughput for ADSM on MVS can be
>estimated to 4 MB/sec (which means 14 GB/Hr) with uncompressed data due
>to limitations in TCPIP. To break this bareer you have to use another
>network connection, another tcpip stack and another adsm server address
>space. In fact, we are reaching something between 2.5-3.5 MB/s. If
>anyone has better performance with uncompressed data, please tell.
>Maybe the new OS/390 2.7 performs better.
>60 GB/hr means ~16 MB/sec which sounds unreachable with a single FDDI
>Connection, maybe the newly announced Gigabit Ethernet OSA for S390 may
>fit. You may think about a dedicated ADSM Server on this machine.
>The improvement with client compression varies from nothing (compressed
>tar's, zips) to a factor of 5 in our environment. Depending on the
>data, we are calculating 1.5-2.5. But - there have been some problems
>with compression (which are solved, as far as I know).
>Regards
>Roger
>
>
>Date:    Tue, 2 Mar 1999 09:53:12 -0500
>From:    Tjeerd Saijoen <tsaijoen AT BFSORG DOT COM>
>Subject: Re: MVS ADSM Server
>MIME-Version: 1.0
>Content-Type: text/plain; charset="iso-8859-1"
>Content-Transfer-Encoding: 7bit
>
>
>
>IBM is working on a better TCP/IP stack I believe it is released already
>but
>I am not sure of that. Also use the MPTHREADING parameter (set this to ON).
>Regards Tj
>
>Date:    Tue, 2 Mar 1999 07:46:33 -0600
>From:    Nathan King <nathan.king AT USAA DOT COM>
>Subject: Re: MVS ADSM Server
>MIME-Version: 1.0
>Content-Type: text/plain
>
>
>
>We're also in this scenario. ADSM MVS (Open Edition) with ATM backbone and
>again rarely see over 1.5 - 2Gb/hr on backups, the only exception is in the
>case of large flat files such as database dumps where we have seen it go as
>high as 4Gb an hour! wow! We have a very small Risc/6000 server
>(Uniprocessor w/512Mbyte Ram) on the same ATM backbone which peforms about
>6
>times better!!!
>We know that there are defnitely a lot of issues with TCP/IP performance on
>MVS. We backup over 1,000 clients each night to 5 ADSM Servers spread
>throughout the sysplex and frequently get lost client tcp/ip sessions
>during
>the course of the night and generally poor performance. TCP/IP on MVS just
>plain stinks. I've lost count of the fixtests, ptfs and hipers that have
>been applied to both TCP/IP and ADSM in an attempt to get around these
>problems. IBM really seem to be chasing their own tail on this one and I
>don't expect TCP/IP on MVS to improve for some time.
>One thing we did do which helped a lot was reserving the appropriate tcp/ip
>sockets on MVS for use exclusively by ADSM. This did provide a lot more
>stability. Perhaps you've been smart enough to do this already. The even
>smarter thing to do would be to migrate off MVS to AIX / NT.
>Regards,
>Nathan
>
>
>
>Hi Virginia,
>we are also locking at ATM for our S/390 Server.
>Do you really get only 1.5 -2 GB per Hour??
>We get 1 to 1.7 GB/Hour already on a 16 MB Tokenring (If everthing works
>well).
>I would expect ATM to give at least 20 GB/Hour.
>Have I missed something or what kind of OSA do you have?
>___________________________________________________
>Kind Regards
>Andreas Buser
>Tel: ++41 61 285 73 21  Fax: ++41 61 285 90 27
>Email: Andreas.Buser AT Basler DOT ch
>
>

Richard C. Dempsey                 email: dempsey AT kodak DOT com
Public Online Services             pager: 716-975-3539
11th Floor, Bldg 83, RL            phone: 716-477-3457
Eastman Kodak Company
Rochester, NY 14650-2203
<Prev in Thread] Current Thread [Next in Thread>