help

[Mile_3]

Hello, I have an Alpha1 4100 running openvms 7-3. We have a KZPAC-CA CONTROLLER RUNING RAID 5 WE HAVE ABOUT 12 4.3 GB DRIVES (ds-rz1cb-vw)
We want to add 3 more raid sets but put them on a DS-DSGGA-AA 8 port Fiber switch controller with 9 36gb Ultra 320 lvd hard drives 15k.
We are running a few nightly jobs which take about 6 hours to finish. What I want to do is once we configure the new raids, I want to put those nightly jobs on that fiber controller. How much faster can we expect our jobs to run with the new fiber controller and disk drives. I am assuming that it will run alot faster than before?
Will it be 5 times, 10 20 faster? Any input would be appreciated? Thanks..Miles

[Mike Naime]

Miles:

-
I do not think that you have all of your parts correct here.
-
What kind of Storage controller are you putting those disk drives into? The SAN switch (DS-DSGGA-AA) that you listed above does not control any disk drives. It simply connects the servers and the Storage controllers with Fibre cables.
-
You will have at least one HBA that you install into the Alphaserver. This will plug into the SAN switch. Also connected into the SAN switch will be the cables from your Storage controller. HSG80 based (BA, MA, EMA), EVA, or MSA1000 are your choices for Fibre channel Compaq/HP storage controller.
-
Welcome to the world of SAN!
-
In a SAN environment, I have seen upwards of 5000 IO/sec on a MON SYS screen on an ES45. What is your current IO throughput on your 4100? I would expect that you could get at least 1000 on the fibre channel. I'm not familiar with the 4100 and it's IO sub-system.

[Martin P.J. Zinser]

Hello Miles,

the exact speedup you will experience is difficult to predict since it does depend on how IO-bound vs. CPU-bound your jobs are. Other important factors are the speed of your FC HBAs and the ports in the switch.

Generally speaking you can expect a considerable performance gain, but you do have to find a balanced configuration where your Server and the IO subsystem have comparable speed. The 4100 is a bit long in the teeth by now (superseeded by ES40, ES45 and
recently ES47). Also if your IOs do contain a good deal of reads and upgrade to 7.3-1 with XFC enabled might be beneficial.

Greetings, Martin

[Paul Jerrom]

Howdy.
Speeding an application depends on a number of things. As the previous respondants have noted, if IO ain't your bottleneck, then removing it won't help! However, if IO is the problem, then you need to find out which type - reads or writes. If your application is write intensive, then running RAID-5 won't help. RAID 0, 1 or 0+1 will be better (dependant on availability requirements and budget). Mirroring can give a performance boost as reads can come from either disk (although if there are more than c.4% writes then it is slower than a JBOD).
Also, you will have more points of latency that you had before - with the KPZPAC you were only travelling down the PCI bus to the controller. Now you have PCI bus, fibre controller, fibre switch, disk controller, disk bus. Plus if it is clustered you'll have multiple cpus competing for the same bus, whch isn't the case with a backplane controller. I note too that while your disks are faster, you'll have fewer spindles - which again could cause a slower response time. Make sure your configuration makes as much use of cache as possible. The fibre controllers can use a truck load of cache, 1GB+, from memory the KZPAC could use something like 8MB. If the app is write intensive then use write back cache (I think the default is write thru, which means your app is stalled until the IO is written to disk). If read intensive, then you want the cache to be as near to the cpu as possible, ie process memory rather than XFC, XFC rather than at the storage controller, controller rather than disk.
But it would be interesting to see what performance change you get with the same applicaiton and two very different storage environments - I wonder if it will be as big an improvement as your salesman suggested!!
Good luck, PJ.

[Richard W Hunt]

I can only relate what happened for us.

We HAD an HS241-J controller & bunch of disks. Bus was SCSI variant. Talking to Alpha 2100.

We went to an HSG80 controller & bunch of disks. Connector was Fiber Channel. Talking to Alpha ES40.

The new disks were 1.5 or 2.0 x spin on the old disks.

Net improvement was 5-20 fold. Things that were CPU bound were not so much faster. But the more I/O bound they were, the better the performance got.

[Martin P.J. Zinser]

Hi,

well Richards experience relates to my earlier statement, they did upgrade both the host and CPU subsytem at the same time ;-) If you are I/O bound you need

a.) a disk subsystem that allows you to perform
the read/writes
b.) a host that is able to generate the I/O requests and process the resulting data.

So, if you do have an I/O bound system now do not be surprised if you are CPU bound after going to FC.

Greetings, Martin

[Hein van den Heuvel]

At the very least you should provide us with the batch job accounting information: elpased, cpu, dirio,...

But you really should make an attempt to articulate what kind of task teh batch job is performing. Is it moving records from one database into an other, updating a bunch of rows? It si a database based job? Have you tuned that DB at all? You might not need any of those IOs! Is the job using RMS (indexed) files? Have they ever been analyzed/tunes/converted?

Cheers,
Hein.