Re: ADSM-L Win2K3 backu
On Feb 1, 2008, at 5:46 PM, Sam Sheppard wrote: Top of message -- 02-01-08 14:42 S.SHEPPARD (SHS)Re: ADSM-L Win2K3 backu Can I infer from you comments that you find the FILE DEVCLASS to be a better performer? This is our first server on Unix; our other 2 TSM servers are running on z/OS and have other known bottlenecks. I hadn't ever considered trying non DISK DEVCLASS for the primary pools. Perhaps I should. FILE devclass has the advantage of being a serially used, sequential disk resource with no simultaneous contention from sessions/ processes, no block management or locking needed, and effectively no repositioning prior to next write. As such, its performance can be far better than DISK devclass. In both devclasses, however, one has to be mindful of the characteristics of the underlying technology. The FILE devclass operates within a directory within a file system, where it is common that the file system is also used for other purposes. As such, free space blocks within the file system may be scattered rather than contiguous, resulting in what is know as Fragmentation and thus performance degradation as repositioning is required to move to the next clump of space - and reposition after having served the other users of the disk. A dedicated file system reduces fragmentation; and a dedicated disk partition can eliminate fragmentation. Repositioning can be eliminated where a disk can be dedicated to the purpose. Naturally, disk arrays and RAID complicate the picture, but in general whatever you can do to provide contiguous, uncontested space results in the best performance. And, of course, this is where tape excels, and why it remains so appealing for backup streaming, not to mention its offered additional features of hardware compression and encryption. Richard Sims
Re: ADSM-L Win2K3 backu
Top of message -- 02-01-08 11:29 S.SHEPPARD (SHS)Re: ADSM-L Win2K3 backu Looks like the problem is with our disk pool. I ran a test directly to LTO3 tape and performance improved dramatically, anywhere from 40 to 70MB/sec. So, I've got my Solaris guy looking at his disk array for potential write problems, since restore performance was not really a problem. Thanks for all of the suggestions. Sam Sheppard San Diego Data Processing Corp. (858)-581-9668 ---` Top of message -- 02-01-08 08:16 ..NETMAIL () Re: [ADSM-L] Win2K3 backu Date: Thu, 31 Jan 2008 20:32:42 -0700 From: Kelly Lipp [EMAIL PROTECTED] Subject: Re: [ADSM-L] Win2K3 backup performance To: ADSM-L@VM.MARIST.EDU _Top_of_Message_ Also set txnbytelimit to themaximum of 2GB (if you have a relatively new = client 5.3 or later) and txngroupmax on the server 1024 (though that is = not really your issue on this client but might be on clients with many = smaller files) =20 Upping txnbytelimit beyond the 25600 default may make a huge difference = as you cut down on your transaction mini-commits dramatically... =20 =20 Kelly Lipp CTO, VP Manufacturing STORServer, Inc. 485-B Elkton Drive Colorado Springs, CO 80907 www.storserver.com http://www.storserver.com/=20 719-266-8777 From: ADSM: Dist Stor Manager on behalf of David Vargas Sent: Thu 1/31/2008 8:12 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Win2K3 backup performance This is what I found to work with our system, with a 1Gb backup network. * TCPWINDOWSIZE 2048 - Maximum setting TCPWindowsize 512 * TCPBUFFSIZE 512 - Maximum setting TCPBuffSize 255 The maximum settings David -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Sam Sheppard Sent: Thursday, January 31, 2008 2:09 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Win2K3 backup performance We have a Windows 2003 client running TSM 5.4.1 backing up to a Solaris 10 TSM server running the 5.4.1 server. The client has several very large files to be backed up (300-400GB). We are finding on a 1.3GB test file that we can only get a throughput of about 10MB/sec (looks like 100Mb speed) even though this client is configured on a GigE VLan. One interesting aspect just discovered is that a restore of the same file got speeds of 37MB/sec, which is about the same as an FTP of the same file from the client to the server. Client, switch, and server all set to 1GB full. At this point, I'm completely mystified as to what might be behind these performance anomalies. I would expect much higher throughput rates on all of these tests, but would be satisfied if the backup would just perform at the same speed as the others. Client options: Server Options: TCPWindowsize 63 TCPWindowsize 131072 TCPBuffsize 32 Thanks Sam Sheppard San Diego Data Processing Corp. (858)-581-9668 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. ---`
Re: ADSM-L Win2K3 backu
Hope that does it for you. Just seems a bit strange only one client exhibits the problem. James Drozynski IBM Pittsburgh Lab 11 Stanwix Street Pittsburgh Pa. 15222 Tel:412-667-4421 Fax:412-667-6975 Tie:989-4421 Sam Sheppard [EMAIL PROTECTED] Sent by: ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU 02/01/2008 02:33 PM Please respond to ADSM: Dist Stor Manager ADSM-L@VM.MARIST.EDU To ADSM-L@VM.MARIST.EDU cc Subject Re: [ADSM-L] ADSM-L Win2K3 backu Top of message -- 02-01-08 11:29 S.SHEPPARD (SHS)Re: ADSM-L Win2K3 backu Looks like the problem is with our disk pool. I ran a test directly to LTO3 tape and performance improved dramatically, anywhere from 40 to 70MB/sec. So, I've got my Solaris guy looking at his disk array for potential write problems, since restore performance was not really a problem. Thanks for all of the suggestions. Sam Sheppard San Diego Data Processing Corp. (858)-581-9668 ---` Top of message -- 02-01-08 08:16 ..NETMAIL () Re: [ADSM-L] Win2K3 backu Date: Thu, 31 Jan 2008 20:32:42 -0700 From: Kelly Lipp [EMAIL PROTECTED] Subject: Re: [ADSM-L] Win2K3 backup performance To: ADSM-L@VM.MARIST.EDU _Top_of_Message_ Also set txnbytelimit to themaximum of 2GB (if you have a relatively new = client 5.3 or later) and txngroupmax on the server 1024 (though that is = not really your issue on this client but might be on clients with many = smaller files) =20 Upping txnbytelimit beyond the 25600 default may make a huge difference = as you cut down on your transaction mini-commits dramatically... =20 =20 Kelly Lipp CTO, VP Manufacturing STORServer, Inc. 485-B Elkton Drive Colorado Springs, CO 80907 www.storserver.com http://www.storserver.com/=20 719-266-8777 From: ADSM: Dist Stor Manager on behalf of David Vargas Sent: Thu 1/31/2008 8:12 PM To: ADSM-L@VM.MARIST.EDU Subject: Re: [ADSM-L] Win2K3 backup performance This is what I found to work with our system, with a 1Gb backup network. * TCPWINDOWSIZE 2048 - Maximum setting TCPWindowsize 512 * TCPBUFFSIZE 512 - Maximum setting TCPBuffSize 255 The maximum settings David -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED] On Behalf Of Sam Sheppard Sent: Thursday, January 31, 2008 2:09 PM To: ADSM-L@VM.MARIST.EDU Subject: [ADSM-L] Win2K3 backup performance We have a Windows 2003 client running TSM 5.4.1 backing up to a Solaris 10 TSM server running the 5.4.1 server. The client has several very large files to be backed up (300-400GB). We are finding on a 1.3GB test file that we can only get a throughput of about 10MB/sec (looks like 100Mb speed) even though this client is configured on a GigE VLan. One interesting aspect just discovered is that a restore of the same file got speeds of 37MB/sec, which is about the same as an FTP of the same file from the client to the server. Client, switch, and server all set to 1GB full. At this point, I'm completely mystified as to what might be behind these performance anomalies. I would expect much higher throughput rates on all of these tests, but would be satisfied if the backup would just perform at the same speed as the others. Client options: Server Options: TCPWindowsize 63 TCPWindowsize 131072 TCPBuffsize 32 Thanks Sam Sheppard San Diego Data Processing Corp. (858)-581-9668 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. ---`
Re: ADSM-L Win2K3 backu
Top of message -- 02-01-08 14:42 S.SHEPPARD (SHS)Re: ADSM-L Win2K3 backu Can I infer from you comments that you find the FILE DEVCLASS to be a better performer? This is our first server on Unix; our other 2 TSM servers are running on z/OS and have other known bottlenecks. I hadn't ever considered trying non DISK DEVCLASS for the primary pools. Perhaps I should. Thanks Sam Sheppard San Diego Data Processing Corp. (858)-581-9668 ---` Top of message -- 02-01-08 12:19 ..NETMAIL () Re: ADSM-L Win2K3 backu From: Richard Sims [EMAIL PROTECTED] Subject: Re: ADSM-L Win2K3 backu Date: Fri, 1 Feb 2008 14:51:23 -0500 To: Sam Sheppard [EMAIL PROTECTED] _Top_of_Message_ On Feb 1, 2008, at 2:33 PM, Sam Sheppard wrote: Top of message -- 02-01-08 11:29 S.SHEPPARD (SHS)Re: ADSM-L Win2K3 backu Looks like the problem is with our disk pool. I ran a test directly to LTO3 tape and performance improved dramatically, anywhere from 40 to 70MB/sec. So, I've got my Solaris guy looking at his disk array for potential write problems, since restore performance was not really a problem. Hi, Sam - If this is a TSM DISK devclass stgpool, that may be the cause of the drag. In my use of DISK, I've been continually disappointed: there seems to be a lot of overhead involved with it, particularly with multiple use, particularly with clients backing up into it and migration happening from it. There seems to be a lot of block management/locking involved. Richard ---`
