Date: Tue, 6 Oct 2009 22:07:24 +0200 From: Thomas Backman <serenity@exscape.org> To: O. Hartmann <ohartman@zedat.fu-berlin.de> Cc: Dieter <freebsd@sopwith.solgatos.com>, freebsd-performance@freebsd.org Subject: Re: ZFS Re: A specific example of a disk i/o problem Message-ID: <74A4B916-9090-40B1-958F-8FF772BD94AB@exscape.org> In-Reply-To: <4ACB068E.2070004@zedat.fu-berlin.de> References: <200910051605.QAA06722@sopwith.solgatos.com> <88D64C60-D8ED-4622-959C-9946DBB99198@exscape.org> <4ACB068E.2070004@zedat.fu-berlin.de>
next in thread | previous in thread | raw e-mail | index | archive | help
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@exscape.org>, >>> Thomas Backman writes: >>> >>>> I run 8.0-RC1/amd64 with ZFS on an A64 3200+ with 2GB RAM and an >>>> old >>>> 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 >>>> disk >>>> 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 >>> interesting: >>> >>> } 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. >> Regards, >> Thomas >> _______________________________________________ >> freebsd-performance@freebsd.org mailing list >> http://lists.freebsd.org/mailman/listinfo/freebsd-performance >> To unsubscribe, send any mail to "freebsd-performance-unsubscribe@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: > http://www.phoronix.com/scan.php?page=article&item=freebsd8_ubuntu910&num=1 > > Watch the threaded I/O impact ... > > Regards, > Oliver 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? Regards, Thomas
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?74A4B916-9090-40B1-958F-8FF772BD94AB>