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>