usually I first check if I get at least 30% of the theoretical performance for a raw device read with dd, then for two reads, then I look at i/o-wait with sar -u and avqueue values with sar -d
i.e. like this:
for platterl in /dev/rdsk/c5t0d1 /dev/rdsk/c7t0d0; do timex dd if=${platterl} of=/dev/null bs=1024k count=200 & done
gathering wio should be done with real application load, because it'll always be close to 100% for a dd (dd basically does nothing but wait for data to push to /dev/null, so what else should I expect)
It's much more interesting combined with aqueue/avserv values under regular database load.
sar -d 3 1 during 2GB dd's over two adapters.
18:46:26 device %busy avque r+w/s blks/s avwait avserv
18:46:29 c1t15d0 2.33 0.50 4 24 2.85 14.75
c3t15d0 2.33 0.50 3 21 3.42 12.93
c7t0d0 98.34 0.50 466 238820 4.92 2.11
c5t0d1 98.67 0.50 475 243072 5.00 2.07
If I worked at a research or CGI site, I'd probably go dig into the performance values and get closer to what marketing people call 'line rate', maybe expecting 300-350MB/s read + 350MB/s write at the same time[*], but where I am the performance requirements are more targeted towards database throughput, which is largely achieved by striping and whatever.
[*] everyone who's about to say these numbers are never achieved in real situations, please just don't. a five year old octane2 could handle well above >600MB/s. :)
yesterday I stood at the edge. Today I'm one step ahead.
