Thomas Backman
Tue, 06 Oct 2009 13:08:29 -0700
On Oct 6, 2009, at 10:57 AM, O. Hartmann wrote:
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.Thomas Backman wrote:On Oct 5, 2009, at 6:05 PM, Dieter wrote:In message <e316139e-ffcf-432f-8dce-62b120c38...@exscape.org>, Thomas Backman writes:Doesn't really help much I'm afraid, since 8.0-RC1 = RELENG_8 = stable/8. Been running current/stable-8 since May.I run 8.0-RC1/amd64 with ZFS on an A64 3200+ with 2GB RAM and an old80GB 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 diskIO. 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 atLEAST 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.Regards, Thomas _______________________________________________ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performanceTo unsubscribe, send any mail to "freebsd-performance-unsubscr...@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
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 _______________________________________________ freebsd-performance@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-performance To unsubscribe, send any mail to "freebsd-performance-unsubscr...@freebsd.org"