performance issue - striping OS on HP 11.0 T520

[Donald Dawson]

I have striped the OS (5 2 GB disks) on 1 controller. The system is an Informix database server. Everything seems to be configured okay, but the system is sluggish - Unix or Informix. There is a perceptible delay on all commands.

Is striping problematic, especially in an OS?

If so, what would be the best way to fix the problem. I can make 5 other drives available.

thanks,
Donald

[Sridhar Bhaskarla]

Hi Donald,

Can you attach (don't post) your vgdisplay -v and lvdisplay -v outputs?.

-Sri

[Patrick Wallek]

I doubt the problem is the striping of the OS. I personally would never stripe the OS, but that's just me.

You've probably got something else going on.

How much RAM? How much swap? Is the swap being utilized (swapinfo -tam)? How many users? How big is the Informix DB? What are the values of dbc_max_pct and dbc_min_pct?

We really need a LOT more info to help you.

[James R. Ferguson]

Hi Donald:

There is no data here to ascertain the root of the problem. Is this a new install? Do you have any other baselines?

'glance' offers the fastest, easiest view into performance. If you don't have a licensed copy, you can install a trial version from the Application CDROM set.

One thing to make sure, on a new install, is the the kernel 'timeslice' parameter is set to 10. If it isn't, you will find that a large fraction of your CPU time may be spent context switching!

Regards!

...JRF...

[Kevin Wright]

striped the OS? I hope you mean that you striped the filesystems your informix DB will reside.

Striping will gain performance by writing columns to multiple disks at the same time.

[Michael Steele_2]

Striping through 1 controller is going to create an I/O bottleneck.

For I/O performance to improve with stripping use multiple controllers.

Attach :

sar -d 5 5

Per process transfer rate is what you need to be evaluating and this includes the block size. In your case 512 bytes (* raw disk *), the stripe extent size, (* usually 32 kb or 64 kb *), or the Informix value, (*??*). Either real big or real small for you're case of 5 disks on one controller. Lots of processes mean real small, one process means real big.

What is the Informix block size?

[Donald Dawson]

Wow, what a response.

I'll work on the information requested and include attachements. Attached is a zip file with the vgdisplay, lvisplay, swpinfo, sar, kernel info, and onconfig:

I am referring just to the OS - vg00. We have had poor response with striping Informix, so we have each 2GB chunk mirrored, but not striped. We have 2k page size.

The timeslice is 10.

I'm not having any luck adding an attachment...

dd

[Donald Dawson]

trying again... zip file with requested info.

dd

[Donald Dawson]

Looks like the zip file did not work. Here is a text file with the info, except for lvdisplay.

Our Informix instance is about 55 GB - 29 chunks. This system used to be our production system, but now is our test system. We have 2GB of memory, 4.5 GB of swap, and only a handful of users.

dbc_max and min are 10/5.

Glance looks good - nothing maxed out.

[Donald Dawson]

Here is the lvmdisplay without the -v option. With the -v option it was over 2 MB

dd

[Donald Dawson]

I'll try sending the full lvdisplay -v as a compressed file.

dd

[Michael Steele_2]

a) swapinfo

dev 512 0 512 0% 0 - 1 /dev/vg00/lvol2
dev 4144 0 4144 0% 0 - 0 /dev/vg01/swap


All priorities should be the same, 1, so update /dev/vg01/swap in /etc/fstab.

b) I'm not sure is I would stripe the O/S.

/dev/vg00/lvol4, 5, 6 and 7 are /opt, /tmp, /usr and /var.

These are vxfs file systems all with a 'Stripe Size of (Kbytes) 8', and more importantly, they are all apart of the O/S.

O/S disks will always display the heaviest usage.

Why use 8 kb instead of the default of 32 kb?

Why stripe a O/S file system?


c)
Average c2t2d0 1.96 0.53 1 17 3.39 18.23
Average c2t6d0 1.36 0.50 1 9 4.79 12.39
Average c2t5d0 1.24 0.50 1 11 2.31 17.04
Average c2t4d0 0.60 0.50 0 5 4.02 15.35
Average c2t3d0 1.08 0.50 1 9 2.29 15.57

There's not a disk or I/O bottleneck problem. Please attach:

sar -u 5 5
sar -v 5 5
vmstat 5 5

If you've got a bottleneck it will be elsewhere.

[Donald Dawson]

Michael,

I had wanted to experiment with striping, but I did not have enough time to test with the default stripe size. I can do so, but now only after hours. I would like to rebuild the OS drives without striping.

Attached is the sar and vmstat.

I have changed swap to level 1 for all of my systems - thanks.

Donald

[Michael Steele_2]

I don't see anything in the latest attachment so I can only assume that LVM has added some delay or latency in with striping. There must be some extra overhead.

Also 2 GB disk technology on a T class server is not going to provide very good performance when compared to an 18 or 36 GB disk on an RP 54## or 74## class server. There is no disk caching for instance and the transfer rate off or on to disk will be slower.

If you have other servers note the 'avserv' times and compare them with your T class. The T class disks will always have larger 'avserv' times. Also note any occasions when 'avwait' > 'avserv,' or %wio is larger then 15. These are potential I/O or tape or disk bottlenecks.