topic very access to disk in Operating System - HP-UX

very access to disk

Astra S A — Mon, 20 Oct 2003 05:18:44 GMT

my friends:
I am with access problem the record in the Glance Disk Util this in 100% in sar - q %runocc this in 100% runq-sz this in 5.5 in sar - d busy this in 70 - 95%
Fibre COOPER
RP5405 ------------> Storage:
11.11 2 Vol in Raid 5
5405 RP non HP product
RAM 4 GB cache 256
can help me?

Vinicius

Re: very access to disk

Michael Steele_2 — Mon, 20 Oct 2003 06:51:13 GMT

Please attache the following:

sar -d 5 5
sar -v 5 5
sar -u 5 5
sar -b 5 5
vmstat 5 5
swapinfo -tam

Re: very access to disk

Astra S A — Mon, 20 Oct 2003 07:25:31 GMT

files ....

Re: very access to disk

Michael Steele_2 — Mon, 20 Oct 2003 08:04:08 GMT

Regarding 'sar -b', you're rcache hits are only 26% and 100% is normal and wcache only 39%, 70% is normal. Usually this indicates new values for 'dbc_min_pct' and 'dbc_mac_pct' are required. Try halfing them. Also list them here.

Regarding 'sar -d', what is on disks c12t0d0 and c14t0d0? The O/S? At 70% they are bottlenecked:

# pvdisplay -v /dev/dsk/c12t0d0 | more (* list logical volume *)

# bdf (* cross ref. lv's from pvdisplay *)

# lvlnboot -v (* list boot disks *)

Regarding "sar -u". Confirms a disk bottleneck.

Where backups being run at this time?

Regarding 'vmstat' some paging is indicated.

Move 2ndary swap out of vg00. (* /dev/vg00/lvol9 *)

Re: very access to disk

Astra S A — Mon, 20 Oct 2003 13:53:20 GMT

Not I understood the meaning of bottleneck.
OS: 11.11

This message in the glance. bottleneck

Re: very access to disk

Michael Steele_2 — Mon, 20 Oct 2003 14:06:55 GMT

Bottleneck means BAD PERFORMANCE and BAD SERVER. It's derrived from congestion or blockage or contention for resources. Remove bottlenecks for GOOD PERFORMANCE and GOOD SERVER.

Please list dbc_mac_pct and dbc_min_pct.

# kmtune -q dbc_max_pct

-or-

Use SAM > kernel parameters

Re: very access to disk

Astra S A — Mon, 20 Oct 2003 14:25:29 GMT

Parameter Current Dyn Planned Module Version
===============================================================================
dbc_max_pct 50 - 50

Re: very access to disk

Michael Steele_2 — Mon, 20 Oct 2003 15:16:23 GMT

OK, so you want to change dbc_max_pct and dbc_min_pct to 10 and 5 perctnt:

# cd /stand/build
# usr/lbin/sysadm/system_prep -v -s /stand/build/system

# kmtune -s dbc_max_pct=10 -S ./system
# kmtune -s dbc_max_pct=5 -S ./system

# /usr/sbin/mk_kernel -s ./system
# mv /stand/system /stand/system.prev
# mv /stand/build/system /stand/system
# kmupdate

#####################################

/dev/dsk/c1t2d0 is your boot disk and its not the problem.

Disk c12t0d0 has /mnt11 and c14t0d0 has /mnt12 and these disks are bottlenecked. One way to resolve this bottleneck is to add more disks and / or disk controllers.

Another way is to defragment /mnt11 and mnt12. Do you have online JFS? Run this command 5 or 6 times if so, and again periodically.

# fsadm -F vxfs -E -e -D -d /mnt11

Finally, why did you call these /mnt11 and 12? Are these NFS file systems?

Re: very access to disk

Jakes Louw — Tue, 21 Oct 2003 00:55:16 GMT

My advice: running lvols one-per-disk is going to give you bad performance.
Instead: perform a full system backup (two to be sure: I don't trust tapes much!).
Then destroy your entire configuration except for VG00: umount, lvremove, vgreduce, vgremove.
Then create a VG with ALL the available disks, and use the "-g" option to create a PVG. The create your lvols using "lvcreate -D y -s g -L -n " as usual. This will use the Distributed Striping option to spread the lvols across all the disks. Your bottlenecks SHOULD then be a thing of the past....
Creating seperate VGs for each disk is bad practice, and since LVM has been around, a redundant practice. Most people with experience of LINUX and older versions of Solaris do things this way, as they are accustomed to partitioned disks.

Re: very access to disk

Michael Steele_2 — Tue, 21 Oct 2003 07:34:19 GMT

Unfortunately I doubt is either will help. Even with stripping the same amount of data will still be hitting both SCSI controllers so its 6 of one or half a dozen of the other. An analogy might be mapped out columns instead of mapped out rows of lvol's on your disks.

About the only thing you can do is to try to reduce the amount of head movement by making the data contiguous via defragging. If you don't have online JFS then backup to tape, newfs the file systems and restore.