Disk Array speed issue

[David Gwin_1]

Hi and thank you to all for taking your time to helping resolve my issue. I have an HP9000 800 Class system, HPUX 10.20 (just recently upgraded from 10.10), 512mb ram, disk array (A3232A) w/ 120gb, and MUX J2092A.

Problem: all activity on the disk array (DA) is extremely slow (deleting, restoring from tape, moving files, etc).

There is a F/W SCSI cable from the computer directly into the DA
The MUX cable splits and goes from the computer into two DDP2 (direct distribution panel) which in turn has two cables from DDP2-A into the DA SPA and SPB

I have tuned the kernel the best that I can. The entire problem may be in how the cables are connected but Iâ m not sure. The system is old but I still have a use for it, unfortunately I cannot find the original hardware-cabling configuration. One additional note, according to SAM/Disks and File Systems panel, the DA SPA is showing a status of â Fault or Absentâ but when I physically look at SPA the status light shows ready

[Steven E. Protter]

The only thing that comes to mind right now is memory. You don't have a lot of memory in there and if you are short that could be a bottleneck.

Your technology on the server is pretty slow and I'm actually amazed you got it to talk to a disk array at all.

I think a used K class running 11.x would provide you substantially better performance on its SCSI bus.

SEP

[David Gwin_1]

I have to use 10.20 because of the software. I have an even older system (HP735) with less memory that manages it just fine.

The system operates as expected when I am reading/writing to the root file system. The root is not part of the disk array.

[Ted Buis]

You probably have HFS for a file system on that old Model 20 array???? Do a bdf and see how full the file systems are. If they are too full you may have a slowdown from that.

You only have one FWD SCSI cable to the array? That would mean a single path. Are you sure it is set up with the second controller, and mirrored cache? Is the light on SPB ready? If your system isn't thinking there is a mirrored cache, then it likely will not reply back that the I/O is complete until written to disk, thus rendering the cache useless which slows down write performance greatly. Are the system and array on a UPS? Is it the same UPS? If so you might dare to change the defauldisk_ir kernel parameter to 1, but it is possible that the array would ignore it anyway. If cache is isn't mirror, and the system is told that the I/O is complete as soon as it is received in cache then there is addition risk of data loss, so the other arrays that I am more familiar with definely wait until the I/O is written to disk incurring the RAID5 write penalty at its worst.

The mux cables are just for management, so I doubt there is an issue there.

[Bill Hassell · Accepted solution]

The cabling will not cause a slowdown unless your syslog.log is full of errors. Look at /var/adm/syslog/syslog.log. If all is well, then hook up a termeinal to the disk array (I assume you have an old Nike array such as a model 20). Look at the stats on each controller (you'll have to move the terminal cable). "extremely slow" is one of those very relative terms. Your system is truly very old but it may also be lacking firmware updates for your controllers. There are a number of performance issues that were resolved with updated drivers and firmware. The problem is that it will be hard to find anyone that remembers what to fix. I asssume you have fully patched your 10.20 system. If not, start with a full set of Gold and HWE patches plus the latest diagnostics from your SupportPlus CDROM (Dec 2001 was the last 10.20 CD). The Nike firmware is stored on a couple of the disks so you'll need HP or a reseller that can provide the latest firmware to update your disk array.