View Single Post
  #1   (View Single Post)  
Old 20th January 2010
J65nko J65nko is offline
Join Date: May 2008
Location: Budel - the Netherlands
Posts: 3,506
Default Immense delayed write to file system (ZFS and UFS2), performance issues

From the FreeBSD stable mailing list:
I realise a strange behaviour of several FreeBSD 8.0-STABLE/amd64 boxes.
All boxes have the most recent STABLE. One box is a UP system, two
others SMP boxes, one with a Q6600 4-core, another XEON with 2x 4-cores
(Dell Poweredge III).

Symptome: All boxes have ZFS and UFS2 filesystems. Since two weeks or
so, sometimes the I/O performance drops massively when doing 'svn
update', 'make world' or even 'make kernel'. It doesn't matter what
memory and how many cpu the box has, it get stuck for several seconds
and freezing. On the UP box, this is sometimes for 10 - 20 seconds.
A very interesting phenomenon is the massively delayed file writing on
ZFS filesystems I realise. Editing a file in 'vi' running on one XTerm
and having in another Xterminal my shell for compiling this file, it
takes sometimes up to 20 seconds to get the file updated after it has
been written. It's like having an old, slow NFS connection with long
cache delays.
These massively delayed file transactions are not necessarely under
heavy load, sometimes they occur in a relaxed situation. They seem to
occur much more often on the UP box than on the SMP boxes, but this
strange phenomenon also occur on the Dell Poweredge II, which has 16GB
RAM and summa summarum 16 cores. This phenomenon does occur on ZFS- and
UFS2 filesystems as well. It is hardly reproducable.
The discussion then focuses on :
The disks involved don't happen to be Western Digital Green Power disks,
do they? The Intelli-Park function in these disks are wrecking havoc
with I/O in Linux-land at least, causing massive stalls and iowait
through the roof during the 25-30 seconds it takes for the heads to
unload after parking. I have two of these disks sitting on my desk now
collecting dust...
Althoug the OP did not use these disks, still a very interesting read
You don't need to be a genius to debug a pf.conf firewall ruleset, you just need the guts to run tcpdump

Last edited by J65nko; 20th January 2010 at 10:35 PM. Reason: boldfacing the disk type
Reply With Quote