Leigh,
Many thanks for your clarifications, they helped a lot !
Cheers.
Arnaud
************************************************************************
******
Panalpina Management Ltd., Basle, Switzerland,
CIT Department Viadukstrasse 42, P.O. Box 4002 Basel/CH
Phone: +41 (61) 226 11 11, FAX: +41 (61) 226 17 01
Direct: +41 (61) 226 19 78
e-mail: arnaud.brion AT panalpina DOT com
************************************************************************
******
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
Leigh Reed
Sent: Wednesday, 12 October, 2005 12:03
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: [SPAM: 10.200] Re: [ADSM-L] Slow backup performance
Arnaud,
I believe that things changed with Windows2000 and above.
This is the note from the manual
Windows 2000 and Windows XP provide a larger TCP receive window size
when communicating with hosts that also provide this support, known as
RFC1323. In these environments, a value greater than 63 may be useful.
Refer to Description of Windows 2000 TCP Features, Microsoft knowledge
base, article 224829, for details regarding TCP features in Windows
2000.
I think that the maximums are as follows
TCPBUFFSIZE 512
TCPWINDOWSIZE 2048
TXNBYTELIMIT 2097152
I personally use the maximums, but there are always trade-offs.
Increasing the buffer size and window size will mean that you require
more resource and the overhead of retransmissions when an error is
encountered is that much higher. However, with today's network speeds
and reliability, coupled with the specification of the latest Intel
hardware, I believe the trade-off is worth it.
The TXNBYTELIMIT setting to the maximum is a recommendation for better
performance when writing straight to LTO1 tape technology (or for that
matter any other tape technology that cannot adapt it's tape streaming
speed)
Using the maximums has worked well for me in the environments I have
used them in.
This doesn't necessarily mean it's gospel. Also bear in mind that your
TSM server has to support the above (ie RFC1323).
Leigh
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
PAC Brion Arnaud
Sent: 12 October 2005 10:00
To: ADSM-L AT VM.MARIST DOT EDU
Subject: [SPAM: 10.200] Re: [ADSM-L] Slow backup performance
David,(others ?)
Like many people here, I'm in a perpetual quest of new tricks for
speeding up the backups in our shop, and thought I could try using the
TCPWindowsize and TCPBuffsize values you provided in your post for some
testing.
To my surprise, the backup speed increased dramatically (50 % gain)as
when compared to the standard settings I was previously using (TCPW 63,
TCPB 31).
However I'm wondering how this is possible, as TSM user manual states
that the TCPWindowsize max value for Windows based systems is limited to
63 !
Do you (or anybody) have an explanation on how this is possible, and
maybe some clarifications about potential side effects of such TCP
settings ?
Many thanks in advance ...
Cheers.
Arnaud
************************************************************************
******
Panalpina Management Ltd., Basle, Switzerland, CIT Department
Viadukstrasse 42, P.O. Box 4002 Basel/CH
Phone: +41 (61) 226 11 11, FAX: +41 (61) 226 17 01
Direct: +41 (61) 226 19 78
e-mail: arnaud.brion AT panalpina DOT com
************************************************************************
******
-----Original Message-----
From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf Of
David Vargas
Sent: Wednesday, 12 October, 2005 02:29
To: ADSM-L AT VM.MARIST DOT EDU
Subject: Re: Slow backup performance
Don't know if this will help, but I thought I'd share what I found when
I was having problems with our Exchange TDP backup performance. In the
dsm.opt file I added -
TCPWindowsize 255
TCPBuffSize 127
My backups went from 800K/sec to 30MB/sec and backup time went from 3
days to 2.6 hours for a total of 290GB of data on a 1Gb network. There
were a couple of other settings that I changed, but this one is what
made it fly. I still think it should be faster...
You may need to adjust the numbers for optimal performance in your
environment.
- David
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of Cameron Ambrose
> Sent: Tuesday, October 11, 2005 1:30 AM
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: [ADSM-L] Slow backup performance
>
> Guys,
>
> Thanks for the info, I'll double check the network settings.
> Though I have changed the COMMtimeout value from 180secs to 1800 secs
> as suggested by Richard Simms, which has stopped the session restart
> error messages and infact the backup seems to be error free.
>
> As for the speed, I'm still leaning towards a tsm netware
> client/ Netware OS issue. I say this because last night I performed a
> test backup on a 10gig volume (50% full) that hadn't had any changes
> and it still took 10 hours to scan only 80000 odd files. The Client
> itself hovered around 87-89% utilisation. When this server was netware
> 6.0 it used to flatline on 100% when performing a backup with the same
> slow performance. We thought once we'd upgraded to 6.5 with the
> additional memory required with 6.5, that performance would improve.
> Unfortunately it hasn't yet. Has anyone experienced this before?
>
> Regards Cameron
>
>
>
> Richard van
> Denzel
> <RvanDenzel@SLTN.
> To
> NL> ADSM-L AT VM.MARIST DOT EDU
> Sent by: "ADSM:
> cc
> Dist Stor
> Manager"
> Subject
> <[email protected] Re: Slow backup performance
> .EDU>
>
>
> 07/10/2005 07:25
> PM
>
>
> Please respond to
> "ADSM: Dist Stor
> Manager"
> <[email protected]
> .EDU>
>
>
>
>
>
>
> Oops, I don't know if there is an iperf for Netware.
>
> Do other clients have the same problems from the network the NW server
> is on? Also you did not specify what kind of network is between server
> and client(s) (100Mb/1000Mb)?
>
> Met vriendelijke groet, With kind regards, Richard van Denzel.
>
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of Leigh Reed
> Sent: vrijdag 7 oktober 2005 10:37
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: Re: Slow backup performance
>
> If you have already checked this and it is very obvious to you, please
> don't be offended, but it has been a very common occurrence throughout
> the life of network backups.
>
> Have you checked that your NIC is hard coded to 100MB Full Duplex and
> your switch is also the same. You could also check if your switch is
> showing any CRC errors. Lastly, try an FTP from client server to TSM
> server to establish if the network is performing outside of TSM.
>
> Again, if I'm teaching you to suck hen produce, apologies.
>
> Leigh
>
> -----Original Message-----
> From: ADSM: Dist Stor Manager [mailto:ADSM-L AT VM.MARIST DOT EDU] On Behalf
> Of Cameron Ambrose
> Sent: 07 October 2005 07:42
> To: ADSM-L AT VM.MARIST DOT EDU
> Subject: [ADSM-L]
>
> Hello,
>
> We're currently experiencing backup failures/extreme slowness on
> a Netware 6.5 SP2 server
>
> TSM Client 5.3.0
> TSM Server 5.2.0
> TSA's up to date as recommended by Client Doco
>
> Client Logs
> 10/05/2005 14:43:19 ANS1809W Session is lost; initializing
> session reopen procedure.
> 10/05/2005 14:43:19 ANS1809W Session is lost; initializing
> session reopen procedure.
> 10/05/2005 14:44:15 sessRecvVerb: Error -50 from call to
> 'readRtn'.
> 10/05/2005 14:44:15 ANS1999E Incremental processing of
> 'SYS:'
> stopped.
>
> 10/05/2005 14:48:24 ANS1999E Incremental processing of
> 'INF:'
> stopped.
>
> 10/05/2005 14:48:25 ANS1017E Session rejected:
> TCP/IP connection failure
>
>
> Server Logs
>
> 10/05/05 14:39:53 ANR0481W Session 2177 for node
> SERVERNAME (NetWare)
> terminated - client did not respond
> within 180 seconds.
> 10/05/05 14:41:10 ANR0406I Session 2178 started for
> node
> SERVERNAME
> (NetWare) (Tcp/Ip
> xxx.xxx.xxx.xxx(19578)).
>
>
>
>
> Currently we have had a backup running for 24 hours and all that
> has been transfered is 4.19 gig and 255,000 files scanned. Has anyone
> else experienced similar issue's
>
> Any help on this would be appreciated
> Regards Cameron
>
The information contained in this e-mail message is intended only for
the personal and confidential use of the recipient(s) named above. If
you are not the intended recipient, you are hereby notified that you
have received this document in error and that any review, dissemination,
distribution or copying of this message is strictly prohibited. If you
have received this communication in error, please notify us immediately
by e-mail and delete the original message. Thank you.
|
