iostat

[xcvzxvzxdv]

HI, can anybody tell what do i infer from this
device bps sps msps

c2t0d0 7 1.6 1.0
c2t1d0 6 1.2 1.0
c12t0d0 13096 55.1 1.0
c12t0d5 0 0.0 1.0
c12t0d2 0 0.2 1.0
c12t0d3 0 0.0 1.0
c19t7d0 37414 216.0 1.0


from which value can I find that IO cokepoints are coming

[RAC_1]

The man page gives following details about values you get. Looking at the description makes me think that this is not very good to look at disk chokepoints. I would rather use sar -d and check which disks have high wait time and %busy.

iostat man page.

Column Heading Interpretation
device Device name
bps Kilobytes transferred per second
sps Number of seeks per second
msps Milliseconds per average seek

[AwadheshPandey]

NAME
iostat â report I/O statistics

SYNOPSIS
iostat [-t] [interval [count]]

DESCRIPTION
iostat iteratively reports I/O statistics for each active disk on the system. Disk data is arranged in a four-column format:

Column Heading Interpretation
device Device name
bps Kilobytes transferred per second
sps Number of seeks per second
msps Milliseconds per average seek
check this link for more details.
http://docs.hp.com/en/B2355-60105/iostat.1.html
cheers,
Awadhesh

[Ninad_1]

Hi,

If these are the only disks on your system or any other disks are also showing very little bps,sps that means your IO is not distributed evenly across disks.
You should try to spread your IO across the disks available.
Having said that - you may have spread IO at storage array level by creating RAID5 LUNs but again at OS level try to distribute across available disks.
Now the high values of bps indicate you have around 13 MB/s and 37 MB/s on the 2 disks and sps means number of seeks per second - corelating the bps and sps you can determine what is the trend or usage of your data - sequential or random. The current pattern shows a sequential pattern.
If there are filesystems on these disks then you will benefit from filesystem buffer cache size being respectable and probably some read ahead settings/parameters on you storage while carving the LUNs.
Also you need to check sar -d to see avwait and avserv times apart from avqueue and %busy times for these disks to see if there is a disk bottleneck.

Regards,
Ninad

[xcvzxvzxdv]

sar -d output is attached. The diice name c19t7d0 is approx busy 56%.. Do i infer that there could be a problem with this

[Ninad_1]

Hi,

From your output of sar
Average c2t0d0 2.96 0.50 8 80 4.66 7.04
Average c2t1d0 1.96 0.50 4 31 4.42 7.83
Average c12t0d7 0.16 0.50 0 7 4.62 2.91
Average c18t5d0 45.42 0.50 349 89052 4.98 3.05
Average c12t0d0 7.64 0.50 30 14258 5.01 3.84
Average c12t0d5 1.60 0.91 11 816 6.05 4.02
Average c19t7d0 56.34 0.63 373 15898 5.12 4.94
Average c12t0d6 0.04 0.50 0 1 3.85 5.13

The figures look safe, no need to worry.
Note that the disk shows 56% busy - thats not the problem -you need to look at the avqueue, avserv and avwait times as well.
All of which are perfectly under limit at the moment. You need to worry if the avserv starts going above 20ms also if avqueue starts building up.

Regards,
Ninad