Re: HP AutoRAID question....

In article <6dk05n$l0q@sjx-ixn6.ix.netcom.com>, Ray Garrison <apsnet@ix.netcom.com> writes: DUDES...I am a hp hareware/informix guy...show this to look at.. 1 - Check the kernel config in sam and make sure that you are not runing the singel user config (the default for HP-UX install) 2 - do a sar -d 1 10 then post data... 3 - do a sar -u 1 10 then post... 4 - call hp support for support and check your patch list to see if up to date...or do a swlist then post 5 - do a vmstat and port... 6 - do a swapinfo and post...common mistake of installs is too little swap/ disk memory.. last do a onstat -p and look at cache stats...post for fun... GREAT DAY!! email to trog48@primenet.com... > In article <34fc9cfe.90032039@10.209.30.200>, > jharris@westpac.com.au (Jason Harris) wrote: > >>Billy, >> >>The main thing have noted on HP performance is that KAIO is slower >>than AIO VPs. But AIO VPs use a lot more CPU resources than KAIO. For >>example an archive on KAIO shows very little CPU usage, about 10% of 5 >>CPUS whereas using the AIO VPs uses 50% of three CPUs plus 5 - 10% of >>the other two. >> >>Which are you using? If the CPU % used is very low then check the IO >>queue info ie onstat -g ioq and onstat -g iov. >> >>We also are using AutoRAID. >> >>Jason >> > > Jason and Billy, > > One thing I have noticed is that Informix seems to be EXTREMELY sensitive > to minor configuration differences on HP platforms. We are an HP9000 > shop, have been for 8 years. I have configured and installed Informix > on HP G, H, K, D and (soon) V class systems, starting with version 4 of > Informix running under HP/UX 9.0x to 7.21.uc3 running on 11.0. I have > never found the same kernel parameters to work as expected with each > move. Most of these systems used lots 'o little disks (25 X 2 gigabyte > FS SCSI typically). On some systems, KAIO ran as much as 20% faster than > AIO VPs did. On other systems, AIO was faster. On some systems, fragmenting > tables across a bunch of small spaces worked best, on other systems dumping > the whole damn thing, indexes and all, into one big chunk worked best. > On some systems, huge amounts of read ahead pages sped things up; on other > systems, made no difference at all. On some systems, multiple CPU VPs, even > to the extent of several more than physical CPUs, worked best; on others, > one CPUVP ran fastest. Keep in mind this is the same damn database, simply > unloaded and loaded as the boxes grew. Same indexing strategy, same relations, > same data, with mucho experimentation on each implementation regarding > fragmentation strategy and kernel tuning. > > Just about the only absolutes I've found: move the logical log, physical log > and root database spaces onto their own drives, preferably the internal > FS SCSI II. Never found a RAID configuration that worked nearly as well > as a bunch of small disks. Always configure several temp spaces, each on > their own physical device; I never use fewer than four (sorting speeds up > dramatically!) > > If anyone else out there has found HP UX and OnLine to be as persnickity > as I have, would enjoy hearing your story. > > Ray Garrison >