On Wed, May 11, 2005 at 12:46:19PM +0100, Patrick Welche wrote:
> [...]
>                                                  pic0 pin 10            9 cow
> Disks:   sd0   sd1   cd0   cd1   sd2             pic0 pin 5            64 fmin
>  seeks                                           pic0 pin 14           85 ftarg
>  xfers                            73             pic0 pin 15       143501 itarg
>  bytes                         4221K         100 pic0 pin 0          1028 wired
>  %busy                           100                                 1068 pdfre

So the disk is 100% busy, it's really a disk or driver issue.

> 
> (the load of 4 is basically: dnetc, cat, ioflush, aiodoned)
> so it really isn't doing anything else...
> 
> (csh built-in time)
> % time cat olddata03_04m > /dev/null
> 0.0u 10.1s 13:25.74 1.2% 0+0k 208+1io 0pf+0w
> % ls -l olddata03_04m
> -rw-r--r--  1 postgres  postgres  3465758203 May 10 18:48 olddata03_04m
> % ls -lh olddata03_04m
> -rw-r--r--  1 postgres  postgres  3.2G May 10 18:48 olddata03_04m
> 
> 3.2G/13:25 wall time = 4.1G, so "progress" seems to be correct...
> 
> 3GHz P4, 2GB ram. A complication, is that sd2 is really 2 disks plugged into
> to the lsilogic raid controller, combining them (striping?), and presenting
> as a singe drive to the OS:

Hum. Can you try a dd on the raw device, and see what speed we get from
a sequential read ?
dd if=/dev/rsd2d of=/dev/null bs=64k count=1000

The next test would be to benchmark each disk individually on the same
controller, to see if it's an issue with the mpt driver, or the raid
stuff in the controller itself. But if the system is in use this may not be
doable.

-- 
Manuel Bouyer <bouyer@antioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la difference
--