Skip site navigation (1)Skip section navigation (2)
Date:      Mon, 8 Feb 2010 17:18:22 +0100
From:      Fabian Keil <freebsd-listen@fabiankeil.de>
To:        freebsd-stable@freebsd.org
Subject:   Re: ATA_CAM + ZFS gives short 1-2 seconds system freeze on disk load
Message-ID:  <20100208171822.12773278@r500.local>
In-Reply-To: <20100208145147.GA3733@icarus.home.lan>
References:  <20100208143329.GA12057@megatron.madpilot.net> <20100208145147.GA3733@icarus.home.lan>

next in thread | previous in thread | raw e-mail | index | archive | help
--Sig_/CV70vSwVb2oMLr7jxC3nJA4
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: quoted-printable

Jeremy Chadwick <freebsd@jdc.parodius.com> wrote:

> On Mon, Feb 08, 2010 at 03:33:29PM +0100, Guido Falsi wrote:

> > I'm seeing this problem on my machine at work. It's an HP DC 7800,
> > mounts an ich9 chipset(not ahci capable). I'm attaching the dmesg.
> >=20
> > I noticed this in the past, but it got evident(and very annoying)
> > while recompiling many ports today after the jpeg-8 update.
> >=20
> > It looks like it freezes the system for the second or two it takes
> > to flush buffers to disk when there are big outputs. This happens
> > when decompressiong big distfiles, mainly. The openoffice port
> > triggers this almost continuosly every few seconds during compilation.
> > I've also seen this when working with big files(for example graphic
> > images in uncompressed formats).
> >=20
> > It gets very annoying and I don't remember this happening before
> > activating the ATA_CAM flag. There was some slowdown with big disk
> > access, but not a total freeze.
>=20
> This happens without ATA_CAM (e.g. using ataahci(4) or any other
> controller driver).

Indeed.

> The behaviour you're describing (bursty heavy disk I/O that stalls the
> subsystem) is pretty much the norm on all FreeBSD systems I've seen with
> ZFS.  When it starts happening, it's easy to notice/follow using "zpool
> iostat 1" or "gstat -I500ms".  Lots of I/O will happen (read or write)
> and the ARC is essentially being thrashed -- said utilities won't show
> any I/O counters incrementing until some threshold is reached, where
> you'll see a massive amount of I/O reported, during which time the
> system is sluggish (beyond acceptable levels, IMHO).  A few seconds
> later, the I/O counters start reporting 0 as the ARC gets used, then
> a few seconds massive I/O, rinse lather repeat.

I experienced what I think is the same problem. ZFS's bulk disk flushes
caused vlc to occasionally stutter when viewing a DVD rip from disk while
ripping a DVD at the same time.

My workaround is to put "vfs.zfs.txg.timeout=3D3" in /boot/loader.conf.
I think I read about this on zfs-discuss@. I assume on faster systems
one can use a higher value.

I'm currently updating the jpeg dependencies, too:

fk@r500 ~ $zpool iostat 1
               capacity     operations    bandwidth
pool         used  avail   read  write   read  write
----------  -----  -----  -----  -----  -----  -----
tank         176G  52.1G     22     40  1.40M  1.85M
tank         176G  52.1G     73      0  9.24M      0
tank         176G  52.1G     73      0  9.05M      0
tank         176G  52.1G     42    176  5.12M  11.3M
tank         176G  52.1G     68      0  8.62M      0
tank         176G  52.1G     67      0  8.43M      0
tank         176G  52.1G     57    106  7.11M  9.54M
tank         176G  52.1G     75      0  9.50M      0
tank         176G  52.1G     76      0  9.62M      0
tank         176G  52.1G     46    167  5.74M  11.7M
tank         176G  52.1G     79      0  9.99M      0
tank         176G  52.1G     81      0  10.2M      0
tank         176G  52.1G     43    164  5.43M  11.7M
tank         176G  52.1G     71      0  9.00M      0
tank         176G  52.1G     61     39  7.74M  5.00M
tank         176G  52.1G     46    111  5.74M  9.17M
tank         176G  52.1G     71      0  8.99M      0
tank         176G  52.1G     80      0  10.1M      0
tank         176G  52.1G     47    113  5.87M  9.68M
tank         176G  52.1G     70      0  8.87M      0
tank         176G  52.1G     78      0  9.80M      0
tank         176G  52.1G     42    164  5.24M  11.3M
tank         176G  52.1G     76      0  9.62M      0
tank         176G  52.1G     79      0  9.99M      0
tank         176G  52.1G     49    153  6.11M  10.8M
tank         176G  52.1G     72      0  9.12M      0

Fabian

--Sig_/CV70vSwVb2oMLr7jxC3nJA4
Content-Type: application/pgp-signature; name=signature.asc
Content-Disposition: attachment; filename=signature.asc

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.14 (FreeBSD)

iEYEARECAAYFAktwOVcACgkQBYqIVf93VJ3u+QCgnudevzboYRjzkRajHNanpHWP
72wAoKiezne4xZRxYAsKdON8OqR6DnxR
=t8D8
-----END PGP SIGNATURE-----

--Sig_/CV70vSwVb2oMLr7jxC3nJA4--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20100208171822.12773278>