Disk speed measure - pat - impossible result

[Laszlo Csizmadia]

Please help me understand something. I have an EMC storage (Clariion CX600) and I wanted to measure its speed. You can do it with pat(Performance Assessment tools): http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?objectID=lpg50460#N10468
Result:
[root@geledwh1:~]$ ./pat -f /db30_dw1p
read 5200.02 MB from 2 files in 35.69 seconds, 145.69 MB/sec
[root@geledwh1:~]$ ./pat -s /dev/vg10dwh/lvol35
read 512 MB at /dev/vg10dwh/lvol35 start in 29.72 seconds, 17.23 MB/sec
[root@geledwh1:~]$ bdf /db30_dw1p
Filesystem kbytes used avail %used Mounted on
/dev/vg10dwh/lvol35 10240000 5328238 4758276 53% /db30_dw1p

This speed is just irreal. And believe me this data just can't be in EMC's cache.
Can somebody explaim me these? I would really appreciate.

[Eugeny Brychkov]

It's logical from this output that when filesystem is mounted it is cached in the host... But it's only a guess
Eugeny

[Laszlo Csizmadia]

I guess the difference comes from the difference between reading rlvol and lvol (rdsk/dsk):
[root@geleclf1:~]$ timex dd if=/dev/dsk/c4t7d2 of=/dev/null bs=64k count=1000
1000+0 records in
1000+0 records out
real 4.11
user 0.00
sys 0.90

[root@geleclf1:~]$ timex dd if=/dev/rdsk/c4t7d2 of=/dev/null bs=64k count=1000
1000+0 records in
1000+0 records out
real 0.63
user 0.00
sys 0.05

Why is it so significant the difference? Why is it possible to dd from dsk/lvol?

[Eugeny Brychkov]

I've tried the same for my internal disks (old 2GB ones...)

# timex dd if=/dev/dsk/c0t4d0 of=/dev/null bs=64k count=1000
1000+0 records in
1000+0 records out

real 50.21
user 0.03
sys 6.02

# timex dd if=/dev/rdsk/c0t4d0 of=/dev/null bs=64k count=1000
1000+0 records in
1000+0 records out

real 13.95
user 0.02
sys 0.35

So you can see that results are the same. Thus it's not a disk array issue. Character type device looks like faster that block one
Eugeny

[Don Capps]

I would use Iozone to do the measurements :-)
http://www.iozone.org

And specify a file size range so that the largest file is bigger than the amount of OS memory, and disk array cache. Then you could see all of the cache effects, as well as the underlying I/O subsystem performance.

Never measure raw devices as they are meaningless to real applications that run on top of the filesystem.

Never use "dd" as a perf tool.
Never use any proprietary perf tool.

Enjoy,
Don

[Vincent Fleming]

You get better performance from the filesystem because of the server's buffer cache. It's not even going to the disk array much.

Block devices are difficult to performance test with because the kernel can/will reschedule the I/Os, and execute them in a different order. They also uses the system's buffer cache.

The raw devices are better because they do what you tell them to - which is do a physical I/O for each and every read() or write() your test executes, and it blocks your process(s) until the I/O is complete, so you can calculate response times. It's a much simpler interface, so it's a little faster.

The use of a commercially available, freeware benchmark (such as iozone, mentioned previously) is an excellent idea. They are much better at simulating different workloads, so you can test more than just sequential I/O - you can look at random as well, and they give better metrics.

Good luck,

Vince