Dead slow system response time on terminls while Tape backup operation.

[Khalique]

Hi

I am using openvms v8.3 running on Integrity rx3600 with two processors and 4 GB RAM. Terminals(Thin clients) are connected using TCP/IP.

Response time on terminals for data entry degraded almost dead slow when any backup process is initiated on tape devices(DAT72 or ultrium 448). Kindly suggest how can I tune the system so that system's response on terminlas could be increased during tape backup.

[Volker Halle]

Khalique,

you first need to better understand, what the bottleneck may be. If you're logged in via TELNET to the system at that time and type some texst at the DCL prompt, is the echoing of the characters slow ? Are the users seeing slow repsone time inside an application ?

What is the overall load on the system, start with MONITOR SYSTEM ? Install and start T4 to provide objective system performance data for analysis.

Volker.

[labadie_1]

As Volker has said, start a tool which will collect some data (Cpu, I/O, locks, memory).

You have monitor (see sys$examples:submon.com for using a basic Monitor) or ECP
http://h71000.www7.hp.com/openvms/products/ecp/index.html
as two basic tools.

Then it will be possible to see what happens.

[Robert Gezelter]

Khalique,

I concur with Volker and Labadie that more information is needed.

In seeing similar situations, I have seen a wide range of causes. With high-speed tape and disk devices, BACKUP often places a heavier load on the system than most routine production activities. Thus, BACKUP often exposes performance tuning issues that are otherwise ignored.

Noting that the users in this situation are connected via TCP, one of my first questions is: is this performance problem visible on the directly connected console? Another, related question is what are the UAF parameters of the account running BACKUP?

- Bob Gezelter, http://www.rlgsc.com

[GuentherF]

Which "backup" program? OpenVMS BACKUP?

If OpenVMS BACKUP is the backup going from a local disk (the users' disk) to a local tape? Or, is there some network connection involved (like with using Data Protector)?

/Guenther

[Jon Pinkley]

Khalique,

Can you please tell us how the disks being backed up (the source of the data) and the tape drives being backed up to (the destination of the data) are connected to the rx3600? Also, are you using VMS Backup or some other backup software? Does the slowdown occur when backing up to tape, restoring from tape, or both?

If the network is involved in the data path, and the network is saturated, that could explain your observation.

Also, a more quantitative description of the slowdown would be useful. To me, dead slow means stopped, but I don't think that is what you meant. Does the slowdown affect only a single application, or everything (including the time to echo characters at a DCL prompt)? If it is affecting character echo, then it is most likely network related, but it is possible that a driver running a high IPL is involved. Comparing response from a connection that does not involve the network (like the Console as suggested by Bob) with a telnet session can provide a good clue as to whether it is network or IPL related. If it is not network related, there are tools that can be used to better understand the problem (SDA extensions for example), but before looking into that, eliminate the more probable causes.

As others have said, BACKUP (by design) can place a high I/O load on the disks being backed up. If the application is using the same drive as you are backing up, they will see an increase in their response times, although with VMS 8.3 BACKUP by default does not place as many I/O requests in the queue as it did in earlier versions of VMS.

$ monitor disks/item=queue_length

will provide a reasonable indicator of relative performance. Long queues are an indication of saturation of the I/O path. Get a baseline when backup is not running, and compare with when backup is running.

T4 will automate the collection of these items and TLViz allows you to analyze the collections on your PC. Although not absolutely necessary for this problem, it is nice to have something collecting all the time so the data is available when you need to investigate a problem.

One work around is to perform your backups when users are not using the system. If that is possible, that is recommended.

If the problem is network related, and due to backup data using the same network as the telnet traffic, you will need to either get a faster network or segregate the backup data from the telnet data by using a separate NIC and VLAN for the backup data.

You could also detune the backup account so it doesn't saturate the disk, but that will make backups take longer.
We need more info to be able to provide better solutions.

Good luck,

Jon

[Hoff]

Ignore what those other folks wrote. Just for now, that is -- the other information here is right, but it's somewhat premature, inferring from your question -- and once the foundation is established, you'll want come back here and re-read some of the other replies.

Have a performance question?

Read this manual RIGHT NOW:

"OpenVMS Performance Management"

It (and the other manuals) are available here:

http://h71000.www7.hp.com/doc/os83_index.html

This performance management manual will present how to investigate, diagnose and tune OpenVMS, a concept and a process which you will then use when you come back here and read some of the other replies and other possibilities. For best outcomes, use a systematic approach toward tuning. And that's what this manual shows.

This could be host load issues, network issues, bus issues, NIC issues, errors, I/O, router issues, anything...

[Wim Van den Wyngaert]

Without investigating : try adding the following just before the backup command.

$ set proc/prio=1

(or use set proc/prio=1/id=xxx when you can't modify it)

Of course this will slow down your backup.

Wim