very access to disk

[Astra S A]

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

[Michael Steele_2]

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

[Astra S A]

files ....

[Michael Steele_2]

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 *)

[Astra S A]

Not I understood the meaning of bottleneck.
OS: 11.11

This message in the glance. bottleneck

[Michael Steele_2]

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

[Astra S A]

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

[Michael Steele_2]

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?

[Jakes Louw]

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.

[Michael Steele_2]

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.