ZFS Re: A specific example of a disk i/o problem
serenity at exscape.org
Tue Oct 6 20:08:06 UTC 2009
On Oct 6, 2009, at 10:57 AM, O. Hartmann wrote:
> Thomas Backman wrote:
>> On Oct 5, 2009, at 6:05 PM, Dieter wrote:
>>> In message <E316139E-FFCF-432F-8DCE-62B120C38E55 at exscape.org>,
>>> Thomas Backman writes:
>>>> I run 8.0-RC1/amd64 with ZFS on an A64 3200+ with 2GB RAM and an
>>>> 80GB 7200rpm disk.
>>>> My problem is that I get completely unacceptable latency on
>>>> console IO
>>>> (both via SSH and serial console) when the system is performing
>>>> IO. The worst case I've noticed yet was when I tried copying a core
>>>> dump from a lzjb compressed ZFS file system to a gzip-9 compressed
>>>> one, to compare the file size/compression ratio. screen(1) took at
>>>> LEAST ten seconds - probably a bit more - I'm not exaggerating
>>>> here -
>>>> to switch to another window, and an "ls" in an empty directory also
>>>> about 5-10 seconds.
>>> You might find the "RELENG_7 heavy disk = system crawls" thread
>>> } I didn't actually solve it or do anything.
>>> } I just upgraded to RELENG_8.
>>> } Now it's behaving more like FreeBSD should.
>>> } I can do sequential reads/writes and still
>>> } use kbd/mouse/X11/buildworld and so on.
>> Doesn't really help much I'm afraid, since 8.0-RC1 = RELENG_8 =
>> stable/8. Been running current/stable-8 since May.
>> freebsd-performance at freebsd.org mailing list
>> To unsubscribe, send any mail to "freebsd-performance-unsubscribe at freebsd.org
> Is this really ZFS-bound? I also saw (and still see!) massive
> performance impacts when a lot of disk activities, especially when
> compiling large packages (done on UFS2 disks). Copying data from one
> ZFS drive to (on different harddrive) another ZFS drive (which is
> compressed) doesn't impact performance that much.
> When the box hit this performance issue, console, X11 and other
> activities tend to be stuck for minutes! This happens on an UP box
> (Athlon64 3500+, 2 GB ECC RAM, 2x 250 GB WD SATA-II disks and 1 TB
> WD SATA-II disk (1x 250 GB UFS2 for system, 1x 250 GB ZFS compressed
> for backup, 1x 1 TB ZFS holding /home).
> But this impact is also noticable on my lab's machine: Quad core
> Intel Q6600 CPU at 3,0 GHZ, 8 GB RAM, 1x 320 GB SATA-II UFS2 disk
> for system, 2x SATA-II 500 ZFS and 1x 750 GB disks ZFS and even on a
> 8 core, two socket Dell PowerEdge 1950-III box with two XEON CPUs
> running at 2,5 GHz, 16 GB RAM and two SATA-II harddrives attached to
> the built in SAS controller.
> Maybe this is of interest:
> Watch the threaded I/O impact ...
It doesn't appear to be an ZFS issue, no. (Note that I wasn't the one
who added it to the subject line :)
I just tried it to my one UFS filesystem, and while screen(1) DID
remain 100% responsive, everything didn't. vim worked OK most of the
time, but other FS ops on the same disk... oh no. I aborted the "file /
etc/*" after 57 seconds. Tried it again after stopping the disk IO
(cat /dev/zero > /bootdir/filename) - 1.52 seconds.
This raises the question: is this some kind of hardware specific
issue? If so, what hardware? I can't think of anything my computer
would have in common with the ones you've listed!
I mean, come on, FreeBSD's IO performance can't be this abysmal for
everybody or nobody would use it for serious applications. Something
must be wrong for a few of us, but where and why?
More information about the freebsd-performance