VMS Client Performance
Hello Everybody, Does anyone out there run the a similar configuration that may be able to help us with a few performance options? TSM Server 4.1.3 running on NT4 Enterprise Edition SP6a ABC Backup Client 3.1.0.1 running on OPEN VMS 7.2-2 Basically we backed up a 3.5gb file to disk which only took around 5 mins but on the restore it took just over 2 hours. Has anyone got any ideas for the options file i.e. TCPWINDOWSIZE or TCPBUFFSIZE as we have left them set to the default settings which was TCPWINDOWSIZE 63 and TCPBUFFSIZE 32. Thanks in advance Paul http://www.phoenixitgroup.com **Internet Email Confidentiality Footer*** Phoenix IT Group Limited is registered in England and Wales under company number 3476115. Registered Office: Technology House, Hunsbury Hill Avenue, Northampton, NN4 8QS Opinions, conclusions and other information in this message that do not relate to the official business of our firm shall be understood as neither given nor endorsed by it. No contracts may be concluded on behalf of our firm by means of email communications. Confidentiality: Confidential information may be contained in this message. If you are not the recipient indicated (or responsible for delivery of the message to such person), you may not take any action based on it, nor should you copy or show this to anyone; please reply to this email and highlight the error to the sender, then delete the message from your system. Monitoring of Messages: Please note that we reserve the right to monitor and intercept emails sent and received on our network. Warning: Internet email is not 100% secure. We ask you to understand and observe this lack of security when emailing us. We do not accept responsibility for changes made to this message after it was sent Viruses: Although we have taken steps to ensure that this email and any attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free.
Re: VMS Client Performance
Paul, I've forwarded this along to the developer to get his ideas. It would appear that there is some network issue causing this. The backup time looks good, obviously. When we start to troubleshoot something like this we'll try a bi-directional ftp of a file. There might be some strange routing in your IP network. While we wait for a response, can you try an ftp from the TSM server to the OpenVMS system and see what kind of time you get? Try it the other way around and compare. Obviously, the times should be close to the same. Choose a reasonably large file for the test. Thanks, Kelly J. Lipp Storage Solutions Specialists, Inc. PO Box 51313 Colorado Springs, CO 80949 [EMAIL PROTECTED] or [EMAIL PROTECTED] www.storsol.com or www.storserver.com (719)531-5926 Fax: (240)539-7175 -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of Paul Bestow Sent: Thursday, December 20, 2001 4:41 AM To: [EMAIL PROTECTED] Subject: VMS Client Performance Hello Everybody, Does anyone out there run the a similar configuration that may be able to help us with a few performance options? TSM Server 4.1.3 running on NT4 Enterprise Edition SP6a ABC Backup Client 3.1.0.1 running on OPEN VMS 7.2-2 Basically we backed up a 3.5gb file to disk which only took around 5 mins but on the restore it took just over 2 hours. Has anyone got any ideas for the options file i.e. TCPWINDOWSIZE or TCPBUFFSIZE as we have left them set to the default settings which was TCPWINDOWSIZE 63 and TCPBUFFSIZE 32. Thanks in advance Paul http://www.phoenixitgroup.com **Internet Email Confidentiality Footer*** Phoenix IT Group Limited is registered in England and Wales under company number 3476115. Registered Office: Technology House, Hunsbury Hill Avenue, Northampton, NN4 8QS Opinions, conclusions and other information in this message that do not relate to the official business of our firm shall be understood as neither given nor endorsed by it. No contracts may be concluded on behalf of our firm by means of email communications. Confidentiality: Confidential information may be contained in this message. If you are not the recipient indicated (or responsible for delivery of the message to such person), you may not take any action based on it, nor should you copy or show this to anyone; please reply to this email and highlight the error to the sender, then delete the message from your system. Monitoring of Messages: Please note that we reserve the right to monitor and intercept emails sent and received on our network. Warning: Internet email is not 100% secure. We ask you to understand and observe this lack of security when emailing us. We do not accept responsibility for changes made to this message after it was sent Viruses: Although we have taken steps to ensure that this email and any attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free.
Re: VMS Client Performance
Paul, Kelly - If the FTP times are similar, then another possible cause of this is that the output disk has file highwater marking turned on (this is the default). Or, the output disk is very fragmented and nearly full. For a restore of such a large file, either of these issues can be a significant. Another item to check is whether the file is marked for contiguous restore or contiguous best try (ABC SHOW BACKUP file /FULL will show this). If so, the restore can take much longer than otherwise unless the disk has very large chunks of free space. I would expect the problem to be either some network issue (one should check the OpenVMS LAN device via LANCP SHOW DEV/COUNTER and possibly LANCP SHOW DEV/CHAR) or the above-mentioned disk issues. To change the file highwater marking: $ set volume/nohighwater device: Note that you probably want to reinstate file high water marking after the restore. It is part of OpenVMS file security and helps prevent disk scavenging. To check the fragmentation state of the disk: 1. Install Compaq's DFO from the condist or the DFU utility from the OpenVMS freeware CD. 2. Run DFO's file analysis command, which does not require a license. Or, run the DFU disk analysis command(s). Finally, it would be interesting to see the summary produced by ABC for the restore. The summary data rate would give us an idea about whether the bottleneck is network (data rate slow) or disk (data rate fast, but wall-clock time long). In the disk case, the problem will be in file allocation not the data transfer portion. For degenerate cases, file allocation can take an enormously long time. So, there are two possible bottlenecks: Network or Disk. Oh, almost forgot. Typically (unless drastically changed) the TCPwindowsize and TCPbuff settings have only marginal affect. I recommend leaving them alone. This is especially true because we see reasonable performance during the backup. Regards, Steve Kelly J. Lipp Storage Solutions Specialists, Inc. PO Box 51313 Colorado Springs, CO 80949 [EMAIL PROTECTED] or [EMAIL PROTECTED] www.storsol.com or www.storserver.com (719)531-5926 Fax: (240)539-7175 -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of Paul Bestow Sent: Thursday, December 20, 2001 4:41 AM To: [EMAIL PROTECTED] Subject: VMS Client Performance Hello Everybody, Does anyone out there run the a similar configuration that may be able to help us with a few performance options? TSM Server 4.1.3 running on NT4 Enterprise Edition SP6a ABC Backup Client 3.1.0.1 running on OPEN VMS 7.2-2 Basically we backed up a 3.5gb file to disk which only took around 5 mins but on the restore it took just over 2 hours. Has anyone got any ideas for the options file i.e. TCPWINDOWSIZE or TCPBUFFSIZE as we have left them set to the default settings which was TCPWINDOWSIZE 63 and TCPBUFFSIZE 32. Thanks in advance Paul http://www.phoenixitgroup.com **Internet Email Confidentiality Footer*** Phoenix IT Group Limited is registered in England and Wales under company number 3476115. Registered Office: Technology House, Hunsbury Hill Avenue, Northampton, NN4 8QS Opinions, conclusions and other information in this message that do not relate to the official business of our firm shall be understood as neither given nor endorsed by it. No contracts may be concluded on behalf of our firm by means of email communications. Confidentiality: Confidential information may be contained in this message. If you are not the recipient indicated (or responsible for delivery of the message to such person), you may not take any action based on it, nor should you copy or show this to anyone; please reply to this email and highlight the error to the sender, then delete the message from your system. Monitoring of Messages: Please note that we reserve the right to monitor and intercept emails sent and received on our network. Warning: Internet email is not 100% secure. We ask you to understand and observe this lack of security when emailing us. We do not accept responsibility for changes made to this message after it was sent Viruses: Although we have taken steps to ensure that this email and any attachments are free from any virus, we advise that in keeping with good computing practice the recipient should ensure they are actually virus free.
Re: VMS Client Performance
You know I had a problem similar to this. We were doing a large restore of a system disk about 50,000 files 1.6Gb. It took about 20 minutes to build the file list. When it started restoring it restored 1Gb fast and then the session hung for 45minutes. So I killed the session from TSM and it reconnected and started moving files again from where it left off but after about 30Mb more it hung again. So I killed the session from TSM again and it reconnected and did another 10Mb and hung again. This happened about 5 times before it completed. I don't understand why it would hang. It wasn't waiting for a tape mount, it would just sit there. It took us 2hours to restore 1.6GB. Richard -Original Message- From: Kelly Lipp [mailto:[EMAIL PROTECTED]] Sent: Thursday, December 20, 2001 2:14 PM To: [EMAIL PROTECTED] Subject: Re: VMS Client Performance Paul, Kelly - If the FTP times are similar, then another possible cause of this is that the output disk has file highwater marking turned on (this is the default). Or, the output disk is very fragmented and nearly full. For a restore of such a large file, either of these issues can be a significant. Another item to check is whether the file is marked for contiguous restore or contiguous best try (ABC SHOW BACKUP file /FULL will show this). If so, the restore can take much longer than otherwise unless the disk has very large chunks of free space. I would expect the problem to be either some network issue (one should check the OpenVMS LAN device via LANCP SHOW DEV/COUNTER and possibly LANCP SHOW DEV/CHAR) or the above-mentioned disk issues. To change the file highwater marking: $ set volume/nohighwater device: Note that you probably want to reinstate file high water marking after the restore. It is part of OpenVMS file security and helps prevent disk scavenging. To check the fragmentation state of the disk: 1. Install Compaq's DFO from the condist or the DFU utility from the OpenVMS freeware CD. 2. Run DFO's file analysis command, which does not require a license. Or, run the DFU disk analysis command(s). Finally, it would be interesting to see the summary produced by ABC for the restore. The summary data rate would give us an idea about whether the bottleneck is network (data rate slow) or disk (data rate fast, but wall-clock time long). In the disk case, the problem will be in file allocation not the data transfer portion. For degenerate cases, file allocation can take an enormously long time. So, there are two possible bottlenecks: Network or Disk. Oh, almost forgot. Typically (unless drastically changed) the TCPwindowsize and TCPbuff settings have only marginal affect. I recommend leaving them alone. This is especially true because we see reasonable performance during the backup. Regards, Steve Kelly J. Lipp Storage Solutions Specialists, Inc. PO Box 51313 Colorado Springs, CO 80949 [EMAIL PROTECTED] or [EMAIL PROTECTED] www.storsol.com or www.storserver.com (719)531-5926 Fax: (240)539-7175 -Original Message- From: ADSM: Dist Stor Manager [mailto:[EMAIL PROTECTED]]On Behalf Of Paul Bestow Sent: Thursday, December 20, 2001 4:41 AM To: [EMAIL PROTECTED] Subject: VMS Client Performance Hello Everybody, Does anyone out there run the a similar configuration that may be able to help us with a few performance options? TSM Server 4.1.3 running on NT4 Enterprise Edition SP6a ABC Backup Client 3.1.0.1 running on OPEN VMS 7.2-2 Basically we backed up a 3.5gb file to disk which only took around 5 mins but on the restore it took just over 2 hours. Has anyone got any ideas for the options file i.e. TCPWINDOWSIZE or TCPBUFFSIZE as we have left them set to the default settings which was TCPWINDOWSIZE 63 and TCPBUFFSIZE 32. Thanks in advance Paul http://www.phoenixitgroup.com **Internet Email Confidentiality Footer*** Phoenix IT Group Limited is registered in England and Wales under company number 3476115. Registered Office: Technology House, Hunsbury Hill Avenue, Northampton, NN4 8QS Opinions, conclusions and other information in this message that do not relate to the official business of our firm shall be understood as neither given nor endorsed by it. No contracts may be concluded on behalf of our firm by means of email communications. Confidentiality: Confidential information may be contained in this message. If you are not the recipient indicated (or responsible for delivery of the message to such person), you may not take any action based on it, nor should you copy or show this to anyone; please reply to this email and highlight the error to the sender, then delete the message from your system. Monitoring of Messages: Please note that we reserve the right to monitor and intercept emails sent and received on our network. Warning: Internet email is not 100% secure. We ask you to understand and observe this lack of security when emailing us. We do not accept responsibility
