Jeremy Chadwick <free...@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.
> >
> > I noticed this in the past, but it got evident(and very annoying)
> > while recompiling many ports today after the jpeg-8 update.
> >
> > 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).
> >
> > 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.
>
> 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=3" in /boot/loader.conf.
I think I read about this on zfs-disc...@. I assume on faster systems
one can use a higher value.
I'm currently updating the jpeg dependencies, too:
f...@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
signature.asc
Description: PGP signature
