Re: Where is the performance bottleneck?

From: Jens Axboe
Date: Wed Aug 31 2005 - 02:28:03 EST


On Wed, Aug 31 2005, Vojtech Pavlik wrote:
> On Tue, Aug 30, 2005 at 08:06:21PM +0000, Holger Kiehl wrote:
> > >>How does one determine the PCI-X bus speed?
> > >
> > >Usually only the card (in your case the Symbios SCSI controller) can
> > >tell. If it does, it'll be most likely in 'dmesg'.
> > >
> > There is nothing in dmesg:
> >
> > Fusion MPT base driver 3.01.20
> > Copyright (c) 1999-2004 LSI Logic Corporation
> > ACPI: PCI Interrupt 0000:02:04.0[A] -> GSI 24 (level, low) -> IRQ 217
> > mptbase: Initiating ioc0 bringup
> > ioc0: 53C1030: Capabilities={Initiator,Target}
> > ACPI: PCI Interrupt 0000:02:04.1[B] -> GSI 25 (level, low) -> IRQ 225
> > mptbase: Initiating ioc1 bringup
> > ioc1: 53C1030: Capabilities={Initiator,Target}
> > Fusion MPT SCSI Host driver 3.01.20
> >
> > >To find where the bottleneck is, I'd suggest trying without the
> > >filesystem at all, and just filling a large part of the block device
> > >using the 'dd' command.
> > >
> > >Also, trying without the RAID, and just running 4 (and 8) concurrent
> > >dd's to the separate drives could show whether it's the RAID that's
> > >slowing things down.
> > >
> > Ok, I did run the following dd command in different combinations:
> >
> > dd if=/dev/zero of=/dev/sd?1 bs=4k count=5000000
>
> I think a bs of 4k is way too small and will cause huge CPU overhead.
> Can you try with something like 4M? Also, you can use /dev/full to avoid
> the pre-zeroing.

That was my initial thought as well, but since he's writing the io side
should look correct. I doubt 8 dd's writing 4k chunks will gobble that
much CPU as to make this much difference.

Holger, we need vmstat 1 info while the dd's are running. A simple
profile would be nice as well, boot with profile=2 and do a readprofile
-r; run tests; readprofile > foo and send the first 50 lines of foo to
this list.

--
Jens Axboe

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/