Date: Fri, 11 Apr 2008 10:33:16 +0100 From: Thomas Hurst <tom.hurst@clara.net> To: freebsd-stable@freebsd.org Subject: Re: Disk I/O Question 7.0-STABLE Message-ID: <20080411093316.GA31354@voi.aagh.net> In-Reply-To: <20080410223153.GA336@FS.denninger.net> References: <20080410223153.GA336@FS.denninger.net>
next in thread | previous in thread | raw e-mail | index | archive | help
* Karl Denninger (karl@denninger.net) wrote:
> I have disks on the internal ICH7 adapters (on the motherboard), SATA,
> and also a TWE controller with two disks.
>
> When hitting the TWE controller hard I can hose the I/O performance on
> the primary (onboard) adapter quite severely to the point that it
> seriously impairs the system's overall performance. "systat -vm"
> shows the primary channels going to 100% busy but the transaction and
> I/O rate count is not all that high. The twe disk I am hammering, of
> course, is saturated (and blowing data at a high rate of speed -
> 70MBps+)
I see exactly the same behavior on a dual dual core AMD box using amr(4)
(8 port LSI MegaRAID SATA) and an 8 port Marvell 88SX6081 ata(4)
controller. I have 3 RAID-1 arrays configured on the LSI and a single
drive on the Marvell; I can freeze up IO to all of them for several
seconds just by running find / >/dev/null for up to 30s.
gstat shows the IO queue for one drive in the high hundreds (all
writes), and it seems waiting for it to flush is what kills the rest of
the system.
My best guess is this is a result of the syncer flushing atime updates.
I should try mounting my /usr noatime and seeing if the problem goes
away. Not the greatest of solutions, but meh.
--
Thomas 'Freaky' Hurst
http://hur.st/
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20080411093316.GA31354>