ADSM-L

Re: Novell performance and TCP/IP problems

1997-04-03 08:11:12
Subject: Re: Novell performance and TCP/IP problems
From: Andrew Raibeck <storman AT US.IBM DOT COM>
Date: Thu, 3 Apr 1997 08:11:12 -0500
Classification:
Prologue:
Epilogue:

Hi Trevor,

The error 60 coming back from the TcpFlush means that the network connection
has timed out (this is not an ADSM timeout, but a network timeout). The other
TCPIP error numbers are simply fallout from that error 60 (error 32 means
"broken pipe" and error 4 means "bad file number"). What kind of error message
is showing up on the ADSM server? You're probably seeing ANR0480W, ANR0481W, or
ANR0482W.

You did not say what version of NetWare you are running. If it's NetWare 3.1x,
then what version of the TCPIP.NLM are you running? You should be at least at
2.75, which is part of Novell's TCP31A.EXE patch (which we supply on the second
ADSM NetWare client diskette).

For performance, try checking the following:

1) Do you have:

TcpMSSinternetlimit OFF

coded in SYS:\ETC\TCPIP.CFG? If not, and if you are going through a routed
network, try adding that line to the file (note that it is case sensitive, and
should be coded *exactly* as I've shown above). You'll need to restart the
TCPIP.NLM in order to have this take effect. If you don't have a TCPIP.CFG
file, then go ahead and create on in SYS:\ETC with that one line.

2) Average file size plays a large role in performance. When the backup
completes, make a note of the average file size as reported in the ending
statistics. A smaller average file size will impact performance.

3) What are your TXNGROUPMAX and TXNBYTELIMIT set to? TXNGROUPMAX is an ADSM
server setting that goes in the server options file. The Q OPT admin command
will tell you what it currently is set to. Try increasing it to 256 (if it
isn't already set to that value). You'll have to restart the ADSM server in
order for it to take effect. TXNBYTELIMIT is an ADSM client setting and goes in
DSM.OPT. Try increasing it to 25600 (if it isn't already set to that value).
You'll have to restart the ADSM client in order for it to take effect. These
values control the size of the transaction that is sent to the server, and can
mitigate some of the performance problems with small files by bundling more
files into a single transaction.

4) Are you using ADSM client compression, either in DSM.OPT (COMPRESSION YES)
or forced by the server (do a QUERY NODE nodename F=D and examine the
"Compression" field)? One other place to check would be in the client backup
schedule, if -COMPRESSION=YES is coded in the OPTIONS field. Unless you have a
very fast processor, client compression will slow things down for you. Try
turning compression off (if you are using it).

5) As you noted, the hardware that the client is running on will also be a
factor in performance. What kind of processor do your NetWare systems use?

6) What are your TCPBUFFSIZE and TCPWINDOWSIZE settings in DSM.OPT? Try setting
them to 32 and 64, respectively.

If all else fails, consider opening an incident with IBM support.

Andy Raibeck
ADSM Level 2 Support
---------------------- Forwarded by Andrew Raibeck/San Jose/IBM on 04-03-97
04:42 AM ---------------------------
04:42 AM ---------------------------

        owner-adsm-l @ VM.MARIST.EDU
        04-03-97 01:31 AM
Please respond to ADSM-L AT VM.MARIST DOT EDU@internet


To: ADSM-L @ VM.MARIST.EDU@internet
cc:
Subject: Novell performance and TCP/IP problems

Trevor Foley
03/04/97 16:57
From:
On:

Hi,

I've got a feeling that this has been discussed before, but I couldn't find
any entries going back through the list for 4 months or so.

We are starting to implement ADSM for our Novell servers. To date we
haven't had a lot of success. First, some information about our
environment.

   Server is 2.1.5.12 running on AIX 4.1.4
   Communcations is entirely TCP/IP
   The network (for the Novell servers) is 10mbit ethernet
   Client version is 2.1.0.6

We have two problems:

   We our getting extremely poor performance, in the order of 200mb/hour.
   As a comparison, we are getting in excess of 1gb/hour from some NT
   servers (admittedly faster CPU, disks, etc.). We have checked the things
   mentioned in the Performance Tuning Guide. The only thing that we have
   changed as a result of that was the TCP/IP MTU size (from 512 to 4000).
   The MTU was already set in excess of 4000 on the Novell servers. The
   volumes on these servers have 10-20 thousand files.
   We are getting a number of TCP/IP failures as show below:

27-03-1997 03:43:45  TcpFlush: Error 60 sending data on Tcp/Ip socket
39358524.
27-03-1997 03:43:45  sessSendVerb: Error sending Verb, rc: -50
27-03-1997 03:43:45  TcpFlush: Error 32 sending data on Tcp/Ip socket
39358524.
27-03-1997 03:43:45  TcpFlush: Error 4 sending data on Tcp/Ip socket
4294967295.
27-03-1997 03:43:45  sessSendVerb: Error sending Verb, rc: -50
27-03-1997 03:43:46  ANS4017E Session rejected: TCP/IP connection failure
27-03-1997 03:43:46  ANS4847E Scheduled event 'BACKUP' failed.  Return code
 = 1.

Any clues?


Trevor
<Prev in Thread] Current Thread [Next in Thread>