Speed Issue - RP8420 attached to IBM FastT200 SAN

[Debbie Beresford]

I have just attached an old FastT200 IBM SAN to our RP8420 machine. The machine has 2 partitions both running HP-UX 11.23.
Since doing this, I have been experiencing speed problems when writing to the disks - as much as 6 times slower. I do see on the SAN that the controllers keep flipping from primary to alternate disks. However, switching primary and alternate on the HP side doesn't seem to help. Both HP and IBM confirm the controllers/fibre cards are good.

Has anyone used this configuration before? any suggestions you can give?

[Steven E. Protter]

Shalom,

I've certainly seen enough slow disk write complaints in my day.

What is the configuration of the LUN's presented to the system? Raid 5 presentations do sometimes lead to slow writes in a write heavy random write environment.

This is less of a problem in a sequential write environment.

If you do a lot of random writes, consider raid 1 or raid 10 lun presentation.

SEP

[Debbie Beresford]

Thanks Steven. The disks are definitely a raid 5. I believe they are used for random writes but I will clarify that before I try to change the raid.

[Kenan Erdey]

Hi,

this is a probably multipathing issue. you could use IBM's multipath software to use one path as preferred.

[TwoProc]

Debbie, there's a lot there to consider. How many disks are in the array supporting your I/O? How many controllers? have enough cache? What raid level? Are the disk segments you used assigned to individual disks, or striped across the whole array, or part of the array?

As for using primary and alternate controller paths, I usually do that by alternating each controller, each san port, and all interfaces into the disk array in each lvol by using PVGs in LVM, and using extent based stripes across them, but there are other ways to get that done as well, some fully automated.

As for most array, especially older ones, many are indeed slower on a single write, but hold up much better with concurrency (like an database) issues, in which your I/O won't degrade nearly as much as a fast local disk will. In this case, the fast local disk will certainly outrun your disk array, but only for one thing at a time operation. An example of this would be copying a large file, say 2Gb. Let's say one at a time the local disk takes 40 seconds to copy(nothing real here just a made up example), if you ran two of these copies at the same time, it will probably take you about 95% longer than copying a single file. And copying three files at the same time will take you almost three times longer.

However, on most large arrays (setup optimally) using the same example, a single copy will take 1/2 to 3 times longer than the single copy of the local disk(depending on the array, configuration, etc). But now, if you kick off a second copy at the same time, the time for both copy 1 and copy 2 concurrently is the same time as just running copy 1 (in this case lets' say 40 seconds). And for three copies at once as well. By the time you run four copies at once, you'll notice maybe it takes 44 seconds, and if you 7 copies at a time, it will take maybe 54 seconds total.

You get the idea? Arrays are systems built for concurrency. If fast writes are necessary for a single process at a time on a server, then a storage array is not your friend. Keep in mind though, that this would describe most times, a workstation, not a server, much less a database server.

Hope this helps a bit.

[Debbie Beresford]

Steven - Sequential writes are happening to these disks. As they were previously working as a raid 5, I have decided to leave them like that for now.

Kenan - One path is already showing as prefered but it keeps flopping.

TwoProc - What you said makes sense, As I was checking to find the answers to your questions, I found that the general cache settings were set to 4KB instread of 16 KB. I have made this change and we will see what happens with our backup tomorrow. I will let you knwo and assign points then.

[Torsten.]

Isn't it an active/passive array device?

In this case the systems polls all available paths - this cause the array to flip the ownership permanently and results in very slow performance.

[Debbie Beresford]

Sorry for my delay in replying. The storage device is active/active. I have been working with both HP and IBM as well as using some of your suggestions but have been unable to improve performance. It looks like my only option is to remove the disks.

Thanks again for your assistance.