ADSM-L

Re: VMS Client Performance

2001-12-20 15:18:38
Subject: Re: VMS Client Performance
From: Kelly Lipp <lipp AT STORSOL DOT COM>
Date: Thu, 20 Dec 2001 13:13:51 -0700
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
lipp AT storsol DOT com or kelly.lipp AT storserver DOT com
www.storsol.com or www.storserver.com
(719)531-5926
Fax: (240)539-7175


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