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-62b120c38...@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-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
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
_______________________________________________
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"
